Commit 6625518cd6 broke cross compiling?
Rob Landley
rob at landley.net
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}/" \
> > CROSS="${ARCH}-" RUNTIME_PREFIX=/ DEVEL_PREFIX=/ -j $CPUS \
> > install hostutils
>
> ARCH=
> 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.
Rob
--
Latency is more important than throughput. It's that simple. - Linus Torvalds
More information about the uClibc
mailing list