[Patch,avr] PR54461: Better AVR-Libc integration

Weddington, Eric Eric.Weddington@atmel.com
Tue Sep 4 15:12:00 GMT 2012



> -----Original Message-----
> From: dosreis@gmail.com [] On Behalf Of Gabriel Dos
> Reis
> Sent: Tuesday, September 04, 2012 9:08 AM
> To: Richard Guenther
> Cc: Georg-Johann Lay; gcc-patches@gcc.gnu.org; Denis Chertykov; Weddington,
> Eric; Joerg Wunsch
> Subject: Re: [Patch,avr] PR54461: Better AVR-Libc integration
> 
> On Tue, Sep 4, 2012 at 9:17 AM, Richard Guenther
> <richard.guenther@gmail.com> wrote:
> 
> >> Can you explain this?  A typical build of avr tools goes like
> >>
> >> 1) configure, build and install binutils
> >> 2) configure, build and install the compiler
> >> 3) configure, build and install AVR-Libc
> >>
> >> so that in step 2 no checking is possible because there is no -lc yet.
> >> Or do you mean a check at run time (of the compiler)?
> >
> > 4) build and install the real compiler
> >
> > at which time you have AVR-libc available.  AT least that's how you
> > "bootstrap" a glibc cross.
> 
> avr-gcc has had a "simplified" build process for a while, as it almost never
> needed to have a avr-gcc hosted on an avr platform.  It is usually
> built as a cross-compiler that always run on the build platform.
> 
> What I was suggesting earlier is that we shouldn't continue patching
> the AVR target as if the current state is almost ideal.  Pick a libc -- avr-
> libc
> appears to be the natural implementation -- and make it the default as
> opposed to adding nobs.

I also strongly agree with this.

AFAIK, the only project that uses newlib as the C library for the AVR target is RTEMS, because, AIUI, they need to have the POSIX interface. The vast majority of AVR users have a toolchain that uses avr-libc.

Eric Weddington



More information about the Gcc-patches mailing list