avr-libc-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Weddington, Eric
Subject: Re: [avr-libc-dev] avr-gcc, libgcc.a and libgcov.a
Date: Wed, 4 May 2011 12:40:23 -0600


> -----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.

Eric



reply via email to

[Prev in Thread] Current Thread [Next in Thread]