On Tue, Sep 4, 2012 at 1:00 PM, Georg-Johann Lay <a...@gjlay.de> wrote: > Weddington, Eric 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. > > So here is an updated version of the patch. > Instead of "with_avrlibc = yes" it does "with_avrlibc != no". > > Just like the first version, --with-avrlibc[=*] is only recognized > if avr-gcc is not configured for RTEMS, i.e. RTEMS users don't need > to set --with-avrlibc=no in order to get a complete libgcc.
Thanks! I am satisfied with this. -- Gaby
