Re: [avr-libc-dev] avr-gcc, libgcc.a and libgcov.a

[Weddington, Eric]

> -----Original Message-----
> From: Chris Marrin [mailto:address@hidden
> Sent: Wednesday, May 04, 2011 7:21 PM
> To: Weddington, Eric
> Cc: address@hidden
> Subject: Re: [avr-libc-dev] avr-gcc, libgcc.a and libgcov.a
> 
> 
> Yes, it is very helpful. One other question is what is the purpose of
> libiberty.a? It's in the path lib/ which seems very odd if it's an AVR
> specific library. Is it just there to allow building the tools? Can I
> ignore it?

Libiberty is a library that comes with GCC (though it can be it's own separate 
library) that has common functionality across multiple platforms, including 
various Linux flavors and Windows. It's known as a "compatability" library. 
It's mainly used in building GCC itself for whatever host is specified.

The reason for the weird name has to do with library names and what GCC 
searches for. GCC uses the -l switch to specify the name of the library to link 
in. However the library name must be in the form of "lib<name>.a". So, for 
example, on the linking command line you will see "-lc" given to GCC. This 
means that GCC will search for the filename "libc.a", which happens to usually 
be the Standard C library for the target compiled for. Well since the filename 
of the library is "libiberty.a", this means that the linker switch to find the 
file must be: -liberty, i.e. 'freedom' from the host system's idiosyncrasies. 
Get it? ;-) 

 
<snip>
> I Like this hierarchy because it keeps all the things that run on the host
> in directories that correspond to the system structure (in fact, you could
> install them in /usr or /usr/local directly and not have any conflicts).
> And it keeps target libraries and includes in avr/. But in looking at how
> gcc does it, they put all the target files into
> 'lib/gcc/<target>/<version>. That's nice because it allows you to have
> different libraries for each version of gcc you have. This is something
> avr-libc doesn't do. You just have to either build the libraries with the
> version of avr-gcc on your machine, or hope they're compatible with the
> compiler you're using.
> 
> So it seems like it would be best to have avr-libc install itself
> alongside the other system files, i.e.:
> 
>       lib/
>               gcc/
>                       avr/
>                               4.5.2/
>                                       include/
>                                               <the avr-libc include hierarchy>
>                                       <the avr-libc lib hierarchy>
> 
> A structure like this would allow you to install everything in /usr/local
> without any avr specific directory paths. Everything in bin has an avr
> prefix, the only thing in etc is avrdude.conf, things in lib are designed
> to go in target specific places, and the man pages all have avr prefixes
> like the binaries.
> 
> I'm going to try to make an installer with this structure, just to see how
> it feels. I'd be happy to work on patching the avr-libc if it seems like
> it would be useful.

Unfortunately, no, it would just add more confusion.

The GCC compiler driver program understands that there may be multiple versions 
of GCC installed. This program driver understands how to look for the proper 
version for it's internal libraries, like libgcc.

But you need to understand that the C library is always a separate project. Any 
target could use different kinds of C libraries, and there are several 
different projects: glibc (gnu c library), newlib, uclibc, eglibc, and others. 
Avr-libc is yet another one in that list, with one beneficial difference: it's 
specific to the AVR target. This means that it's optimized well for the AVR and 
it also contains other AVR specific functionality beyond just the standard C 
library, which in our case is a good thing.

Because all of these C libraries are not a part of GCC, GCC does not internally 
know what to do if multiple versions of the C library are installed. How could 
it know? Which one should it link to? Especially in our case, the C library is 
built after the compiler is already built. This is why there is only one 
version of the C library installed at a time.

Also, most users would be confused if confronted with multiple C libraries in 
their installation. Which one should they use?

Typically the latest version of avr-libc is the best one to choose, unless 
there is something really broken on the latest release (we've had one of those 
recently, but luckily those instances are rare).

So my best advice to you: pick the latest release of avr-libc, build and and 
install it. You usually can't go wrong. This philosophy has been working for 
users of WinAVR for the last 8 years, typically without much issue or complaint.

HTH,
Eric Weddington