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

[Chris Marrin]

On May 4, 2011, at 11:40 AM, Weddington, Eric wrote:

> 
> 
>> -----Original Message-----
>> From: Chris Marrin [mailto:address@hidden
>> Sent: Wednesday, May 04, 2011 12:30 PM
>> To: Weddington, Eric
>> Cc: address@hidden
>> Subject: Re: [avr-libc-dev] avr-gcc, libgcc.a and libgcov.a
> 
>> Thanks for the response. The problem with all this is that there is some
>> overlapping functionality between avr-libc and libgcc. In fact each have a
>> version of stdint.h. Which is the right one to use? It seems like it would
>> be much better if avr-libc provided all the functionality from the libgcc
>> files that can be used with avr-gcc. Or at least they should be at
>> compatible places in the hierarchy. avr-libc includes are at "avr/include"
>> while libgcc includes are at "lib/gcc/avr/4.5.2/include"! I was only able
>> to find the libgcc files by scouring through the installed files.
> 
> Luckily, for your AVR application, you don't need to know exactly where the 
> header files are located, unless you want to go peek inside. See the avr-libc 
> manual for each of the headers.
> 
> Basically for standard include files, include them as normal in the angle 
> brackets like so:
> 
> #include <stdbool.h>
> 
> For the AVR-specific system files, include them with the angle brackets and a 
> leading "avr/" subdirectory, like so:
> 
> #include <avr/io.h>
> 
> The compiler will know where to pick them up automatically.
> 
> As to duplicate effort, yes, we probably should look into that closer. For 
> example the duplicate stdint.h. Offhand, I don't know why that is the case.
> 
> There is some code that is in libgcc that needs to be in libgcc. But yes, it 
> can be a bit confusing when some startup code is in libgcc and some startup 
> code is in avr-libc. I looked into that a while back, and suggested to the 
> other developers that we should have it in one place, and I suggested that it 
> should be avr-libc. One of the other developers (Anatoly, IIRC) suggested 
> that it should really be all in libgcc. And that's where the discussion left 
> off. :-/ So there's not a consensus yet as to what should be done.
> 
> However, one of the nice things about the AVR port of the toolchain, is that 
> surprisingly, everything Just Works without much effort on the part of the 
> user and that is one of things that we, as developers, strive for.
> 
> Hopefully this helps and doesn't cause additional confusion.

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?

In my packaging I have this structure:

        avrtools/
                bin/
                        avr-gcc
                        ...
                libexec/
                        <support for gcc>
                lib/
                        <libgcc and friends, including headers>
                etc/
                        avrdude.conf
                share/
                        man/
                                man1/
                                        <man pages for binaries>
                avr/
                        include/
                                <avr-libc includes>
                        lib/
                                <avr-libc libraries>

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.

I'll post the installer when it's ready, so anyone can try it if they like.

-----
~Chris
address@hidden