[oe] Eureka! AVR32 ld-uClibc.so segfault solved

[Geoffrey Wossum]

Hi all,

I just tracked down the culprit for my AVR32 system always segfaulting 
whenever ld-uClibc.so ran (usually as soon as the kernel attempted to run the 
init process).

Turns out that while most of uClibc is not particularly sensitive to the 
CFLAGS, ld-uClibc.so is extremely sensitive.  The uclibc.inc file was doing 
some things that screwed up the CFLAGS being used to compile ld-uClibc.so.

Here's the diff that made it all work:
--- uclibc.inc  7 Mar 2008 21:50:53 -0000       1.3
+++ uclibc.inc  12 Mar 2008 20:35:44 -0000
@@ -70,7 +70,7 @@

 # do_stage barfs on a CC with whitepspace, therefore put the 'HOST_CC_ARCH' 
in
 # the CFLAGS (for when building the utils).
-OEMAKE_NO_CC= "'OPTIMIZATION=' 'CPU_CFLAGS=${CFLAGS}' 'STRIPTOOL=true' 'LD=${LD}'\
+OEMAKE_NO_CC = "'STRIPTOOL=true' 'LD=${LD}' \
                'LOCALE_DATA_FILENAME=${UCLIBC_LOCALE_FILE}'"
 EXTRA_OEMAKE = "${OEMAKE_NO_CC} 'CC=${CC}'"
 EXTRA_OEMAKE_task_do_populate_staging = "${OEMAKE_NO_CC}"


Now, I'm not sure what consequences this has to the overall system and other 
platforms.  I'm not exactly sure why you'd always want to wipe out the 
OPTIMIZATION and CPU_CFLAGS that the uClibc Rules.mak sets up, either.  
Comments on these points?


So I now have a working OE based AVR32 build system, using binutils 
2.17.atmel.0.0.99 20060623, gcc 4.2.1-atmel.1.0.3, and uClibc 0.9.29-atmel.1.  
This is essentially the same as Atmel's buildroot-avr32-v2.1.0.  As soon as I 
clean stuff up a little, I'll submit patches for this via bugzilla.  Minus 
this uclibc.inc diff.  I need more expert opinion on this.

Thanks to all those who helped!
---
Geoffrey