[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [avr-chat] Can't Install avr-gcc in FreeBSD
From: |
David Brown |
Subject: |
Re: [avr-chat] Can't Install avr-gcc in FreeBSD |
Date: |
Sun, 19 Aug 2007 00:58:11 +0200 |
User-agent: |
Thunderbird 2.0.0.6 (Windows/20070728) |
Joerg Wunsch wrote:
David Brown <address@hidden> wrote:
The msp430 port of gcc, as an example, is a perfectly solid port of
gcc (albeit somewhat out of date), but installation on Linux, last I
checked, involves getting the gcc source tarballs, then patching
based on the cvs versions of the msp430 patches.
That's due to their disconnected development. I never really
understood why they did not integrate the MSP430 port into the regular
GCC source tree but maintain it outside. Supposedly, there are a few
more GCC targets operated that way.
There are quite a few gcc targets that are outside the tree - being in
the FSF tree gives a number of advantages, but has a significant cost.
For some port developers, the requirement of assigning copyright to the
FSF is too much (this could be one of the reasons why Altera, Xilinx,
and Microchip keep their ports outside the tree, but it's unlikely to be
a reason for the msp430 people since the msp430 binutils port is inside
the FSF tree). For others, it's the red tape involved in getting
approval, or perhaps the commitments required in keeping the port
up-to-date. Some might feel that since they have to keep development
versions outside the main tree anyway (in order to integrate support for
new devices faster than official gcc releases, for example), then they
have an easier job of it if everything is outside. I don't know the
particular reasons for the msp430 port, but they certainly seem to be
fairly happy just making minor revisions to their gcc 3.2.3 (IIRC) port,
rather than moving to a newer version of gcc. This is one reason why I
am now going back towards using more avr devices rather than msp430,
even though the msp430 is a far more C-friendly cpu.
For a different example, look at the ColdFire port of gcc. This is more
like avr-gcc, in that it's a full official port, with newer development
versions available which are pushed back to the main tree (although in
this case there's a commercial company running the development).
Installation on windows is via an installer from www.codesourcery.com.
They also have an easy installation of the binaries on Linux, which I
gather will work on many distributions. But on BSD you probably have to
download the source tarballs (also provided, of course) and compile it
yourself.
There are certainly plenty of things that are easier to work with in
*nix, although I haven't found doxygen to be a problem under windows
(I haven't tried running the avrlibc source through it).
It's not doxygen itself, but the generated documentation requires all
sorts of other things, not only LaTeX but also dot and thus Qt.
dot does not need Qt on windows (or if it does, the required libraries
are included in the windows installation of graphviz). Perhaps I've
been particularly lucky (I've had both LaTeX and graphviz installed on
my machine from before I'd even heard of doxygen), or Eric has been
particularly unlucky, but it did not cause me trouble.
The real pain is often cygwin and it's assorted dll conflicts - ...
Right. It eventually boils down to the Win32 API not offering an
option for a thoroughly backwards compatible shared library versioning
scheme, something not only Cygwin suffers from but also many Windows
applications. Strange enough, Windows users appear to tolerate that
design flaw as God-given, but then complain about how cumbersome *nix
systems are to use. ;-)
dll-hell is not nearly the problem it used to be, in my experience.
There was a time when every windows program copied its dll's into the
windows directory, and happily copied old versions over newer versions,
or incompatible versions with the same names. But now most programs
seem to keep the majority of their dll's to themselves, while many
common dll's (such as development tool's run-time libraries) often have
their version numbers in their names. It's not nearly as elegant as
*nix systems have, as it basically makes all libraries private to the
application they came with. On *nix, shared libraries take less disk
space, less memory space if two programs use the same library, and the
libraries can be updated independently of the applications - all of
which is lost on windows because the system is broken. But these
problems are mostly hidden from the user (who just has to buy more
memory, bigger disks, and faster processors). The only real problem I
see with dll's is when a dll changes regularly, and programs cannot cope
with different versions - thus well over 90% of my dll problems are
caused by cygwin1.dll. I see many open source projects moving from
cygwin to mingw for precisely this reason (mingw has less run-time
overheads, which is a bonus), and this progress has made my life much
easier.
I haven't tried FreeBSD ports, but I gather it is similar to Gentoo's
system - ...
Guess where Gentoo has inherited its Portage from. ;-)
I believe (from what I've read) that many of the details are different,
but there's no doubt where Gentoo copied their ideas.
In FreeBSD, a "port" is the "recipe" you're mentioning, and a package
is the binary package compiled out of it, which includes all
dependency information so the installer can automatically install the
Am I right in thinking that you download the port, then the source code
(either as part of the port, or referenced by the port?), and the
compilation to binary is done on your machine according to the rules in
the port, and this binary package is then installed on your machine? Or
is it possible to download a pre-build binary "port"? With Gentoo, you
can do both, with source-only packages being the norm for most programs,
and binary-only being convenient for things like OpenOffice (which can
take days to compile). With Debian, the binary packages are the norm,
although it's fairly straightforward to get hold of the corresponding
source packages.
dependencies. In effect, that's the same as WinAVR is offering to a
Windows user, except you've got a finer level of control about what to
install. So for example, you can opt to install just avr-libc and
avr-gcc (which will require avr-binutils), but leave out avr-gdb,
Insight and everything else that ships bundled with WinAVR.
That choice could of course be added to the windows installer for
WinAVR, and I'm sure Eric would do so if people wanted it.
If someone would really believe a FreeBSD-AVR port would make sense,
it could be set up as a meta port installing everything related to the
AVR, including the kitchensink (usually called a "meta port"). That
would be the FreeBSD equivalent of WinAVR. So far, nobody requested
this though. Ports like this one exist for suites like Xorg
(everything related to the X.org X11 distribution), or Gnome and KDE.
That sounds much like the meta packages in Debian. They are
particularly useful if you have multiple packages that are often used
together, but may be updated separately. That way if a bug is fixed in
konquorer, for example, then an update of the kde-desktop package will
download a new version of the konquorer package without downloading the
whole lot. I don't expect avr-gcc and friends are big enough for that
to be a big issue, however.
mvh.,
David
- RE: [avr-chat] Can't Install avr-gcc in FreeBSD, (continued)
- RE: [avr-chat] Can't Install avr-gcc in FreeBSD, Eric Weddington, 2007/08/15
- Re: [avr-chat] Can't Install avr-gcc in FreeBSD, Bob Paddock, 2007/08/16
- Re: [avr-chat] Can't Install avr-gcc in FreeBSD, David Brown, 2007/08/16
- RE: [avr-chat] Can't Install avr-gcc in FreeBSD, Eric Weddington, 2007/08/16
- Re: [avr-chat] Can't Install avr-gcc in FreeBSD, Joerg Wunsch, 2007/08/17
- RE: [avr-chat] Can't Install avr-gcc in FreeBSD, Eric Weddington, 2007/08/17
- Re: [avr-chat] Can't Install avr-gcc in FreeBSD, David Brown, 2007/08/18
- Re: [avr-chat] Can't Install avr-gcc in FreeBSD, Brian Dean, 2007/08/18
- Re: [avr-chat] Can't Install avr-gcc in FreeBSD, David Brown, 2007/08/18
- Re: [avr-chat] Can't Install avr-gcc in FreeBSD, Joerg Wunsch, 2007/08/18
- Re: [avr-chat] Can't Install avr-gcc in FreeBSD,
David Brown <=
- Re: [avr-chat] Can't Install avr-gcc in FreeBSD, Brian Dean, 2007/08/18
- Re: [avr-chat] Can't Install avr-gcc in FreeBSD, David Brown, 2007/08/19
- Re: [avr-chat] Can't Install avr-gcc in FreeBSD, Joerg Wunsch, 2007/08/19
- Re: [avr-chat] Can't Install avr-gcc in FreeBSD, David Brown, 2007/08/20
- RE: [avr-chat] Can't Install avr-gcc in FreeBSD, Eric Weddington, 2007/08/20
- RE: [avr-chat] Can't Install avr-gcc in FreeBSD, Eric Weddington, 2007/08/20
- Re: [avr-chat] Can't Install avr-gcc in FreeBSD, David Brown, 2007/08/20
- Re: [avr-chat] Can't Install avr-gcc in FreeBSD, Bob Paddock, 2007/08/20
- Re: [avr-chat] Can't Install avr-gcc in FreeBSD, David Brown, 2007/08/20
- RE: [avr-chat] Can't Install avr-gcc in FreeBSD, Eric Weddington, 2007/08/20