Re: [avr-libc-dev] Porting RTEMS patches to avr-libc

[Cynthia Rempel]

Sorry for taking so long to get back to you...

From: Georg-Johann Lay address@hidden
Sent: Wednesday, January 09, 2013 4:59 AM
To: Cynthia Rempel
Cc: Joel Sherrill; Weddington, Eric; address@hidden
Subject: Re: [avr-libc-dev] Porting RTEMS patches to avr-libc

Cynthia Rempel wrote:
> The bugs that were listed on the avr-libc bug-tracker looked resolved...
> although I'm currently experiencing the joys of trying to get the svn
> version of avr-gcc to compile (for testing purposes :). Just stumbled across
> ATMEL's Linux Toolset w/patches,
> http://distribute.atmel.no/tools/opensource/Atmel-AVR-Toolchain-3.4.1/avr/ ,
> hoping up-to-date patches will help...

avr-gcc should build out of the box.  No patches are needed.  What problems did
you encounter?

I didn't realize that avr-libc was using gcc-4.6.2...

I was building the experimental branch of gcc-4.8.0... the problems I 
encountered were related to typical errors caused by making a gcc 
cross-compiler: could not create executables, general build errors, etc.  But I 
found out the typical method for building avr-gcc was to use make -k.

../combined/configure \
 --target=avr \
 --program-prefix=avr- \
 --disable-shared \
 --disable-nls \
 --disable-libssp \
 --with-system-zlib \
 --disable-libada \
 --enable-languages=ada,c,c++ \
 --enable-cpp \
 --with-dwarf2 \
 --enable-version-specific-runtime-libs \
 --prefix=$PREFIX/gcc-testing/install

Once I got the experimental branch working, I had issues building avr-libc with 
it, putting the experimental gcc in the path, and only building the atmega128 
seemed to help
./configure \
 --prefix=$PREFIX/gcc-testing/install \
 --build=i686-pc-linux-gnu \
 --host=avr \
 CFLAGS=-mmcu=atmega128

Then I used WinAVR to run gcc-testing, and got enough good results, I decided 
to move forward with AVR-Ada, promptly ran into build problems even with make 
-k, and am having to slog through applying the binutils patches to the 2.24 
experimental branch... (it looks like there's about 20 now...)  I'm not sure 
what the procedure for submitting the upstreamed patches is...

If the patches could be upstreamed though, it would lower the learning curve 
for AVR-Ada, and thus AVR-RTEMS, if AVR-RTEMS turns out to be feasible...

>> If RTEMS wants to use avr-libc, extending --with-avrlibc seems warranted
>> so that is covers avr-rtems, see PR54461.
> ...if --with-avrlibc would get the svn avr-gcc to compile that would be very
> helpful! Until then, I'll play with trying to upstream ATMEL patches...

--with-avrlibc is mainly an optimization thing to endure basic float arithmetic
from libm.a is used and not the one from libgcc.a.

Again, avr-gcc should build out of the box, no matter how --with-avrlibc is set
and no extra patches are needed.

Johann