Re: [avr-chat] Can't Install avr-gcc in FreeBSD

[David Brown]

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