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

[Geoffrey Wossum]

On Friday 14 March 2008 12:36:46 pm Leon Woestenberg wrote:
> Hello Geoffrey,
>
> On Thu, Mar 13, 2008 at 8:17 PM, Geoffrey Wossum <geoffrey at pager.net> wrote:
> > On Wednesday 12 March 2008 02:50:09 pm Geoffrey Wossum wrote:
> > ...
> >  I just submitted all my patches for the AVR32 to OE's bugzilla.  They
> > are ...
> >  All of the patches are straight forward, except for patch to uclibc.inc
> >  (attachment #8196).  Some one who knows more about why CPU_CFLAGS and
> >  OPTIMIZATION were being overridden by uclibc.inc needs to comment about
> > the effect this change would have on other platforms.  This is really the
> > important patch, since without it you can't build a working ld-uClibc.so.
>
> Good question. I had a similar question about something that wasn't
> trivial in the (uclibc) bitbake recipe.

I'm beginning to think no one actually remembers why this change was made.  I 
located the comment for this change in monotone (it's from 2005-08-11):

---begin--
This set of changes ensures that TARGET_CC_ARCH is passed reliably to all 
packages in a build.  The change fixes problems in the following packages:
<snip>
 | |   uclibc{,-initial}_0.9.27
| | | TARGET_CC_ARCH added to the do_compile.  For the do_stage step the
| | | build actually compiles target code (make utils), but this will not
| | | accept a CC with whitespace.  The TARGET_CC_ARCH flags have therefore
| | | been added to CFLAGS (a bit ugly, but it works).
---end---

My current opinion is that this may have been change made to help debug this 
problem, but wasn't really part of the solution and wasn't intended to be in 
the patch.
 
Even if this was really a fix for a problem on another platform, since it 
breaks at least one platform (AVR32), it wasn't an optimal solution.   Since 
the patch to stop overriding CPU_CFLAGS and OPTIMIZATIONS was applied, I 
guess we'll found out soon if another platform need this :)

---
Geoffrey