Commit 6625518cd6 broke cross compiling?

Rob Landley rob at
Sun Sep 6 04:43:02 UTC 2009

On Saturday 05 September 2009 06:42:29 Bernhard Reutner-Fischer wrote:
> On Fri, Sep 04, 2009 at 03:07:23PM -0500, Rob Landley wrote:
> >Before the August 25 commit "default ?conf to native arch", I could do
> > this:
> >
> >make KCONFIG_ALLCONFIG=miniconfig-uClibc.$ARCH allnoconfig &&
> >make KERNEL_HEADERS="${STAGE_DIR}/include" PREFIX="${STAGE_DIR}/" \
> >  install hostutils
> We _could_ default to the configured arch, if
> - a .config exists and
>   ifeq ($(origin ARCH),command line) or undefined
> if people prefer that logic. My setup now always passes the ARCH but as
> you prefer.

Sorry if I'm behind on this thread, I started my annual caffeine detox two days 
ago and have spent most of the time since then sleeping.  (And of course _now_ 
they restock the orange mango passion fruit rockstar drinks.  Grumble.)

I never previously supplied ARCH= to the build because no uClibc before now 
ever needed it.  I can start doing so (redundant as it seems in this context), 
but could you confirm that the ARCH names you need will consistently match the 
2.6 kernel?  Even when the kernel does things like the ppc->powerpc migration?  
How will you handle somebody building for ARCH=x86 (which works fine in the 
kernel, "ARCH=i386" is a synonym for ARCH=x86 with CONFIG_64BIT=y forced on).

Also, are you planning on hiding the existing architecture selection menu now 
that you've changed how you prefer to configure this stuff?

Oh, and documenting this somewhere might be nice.  This is a big change from 
the entire history of uClibc, I'm not the only one it's going to hit.

If you were going to make it so the .config file no longer contained any 
configuration-specific information, so I could use the same config file for 
several different target architectures, that change might actually be useful to 
me.  (Although not really, because there would still be different floating point 
options and such on some architectures.)  But requiring this information to be 
_redundantly_ specified has no obvious benefit, and duplicating an architectural 
limitation of the kernel's kconfig layout which uClibc never suffered from makes 
no sense.

Latency is more important than throughput. It's that simple. - Linus Torvalds

More information about the uClibc mailing list