Commit 6625518cd6 broke cross compiling?
Rob Landley
rob at landley.net
Mon Sep 7 04:26:59 UTC 2009
On Sunday 06 September 2009 07:22:56 Bernhard Reutner-Fischer wrote:
> 2009/9/5 Mike Frysinger <vapier at gentoo.org>:
> > On Saturday 05 September 2009 14:14:40 Bernhard Reutner-Fischer wrote:
> >> On Sat, Sep 05, 2009 at 08:12:48AM -0400, Mike Frysinger wrote:
> >> >leveraging $(ARCH) makes sense in my mind and aligns it with the build
> >> > systems we are copying from ...
> >>
> >> Ok, i'll have a look sometimes next week.
> >
> > i thought we were already leveraging $(ARCH) :)
> >
> > when i want to do a Blackfin defconfig, i do:
> > make CROSS_COMPILE=bfin-linux-uclibc- ARCH=bfin defconfig
>
> We do. There seems to be irritation that you had to always pass ARCH
> (even after configuration).
I think the sudden undocumented behavior change had something to do with it,
especially breaking an existing code path that used to work, and adding a new
mechanism to specify architectures without removing the old one (which is
still there but no longer works).
I never passed ARCH= to the configure or build stages of uClibc. I never
needed to. I just selected the architecture I wanted to build via menuconfig,
saved it in the .config, and built. That worked fine consistently for seeral
years (at least back to 0.9.26, before which I wasn't really cross compiling
the thing), until the commit on the 25th broke it.
Menuconfig still starts with a "Target Architecture" menu. I just fired it up,
switched that config from i686 to arm (making sure it was a change so it
wouldn't cache old values), and saved it. Here's what the .config it saved
starts with:
#
TARGET_ARCH="x86_64"
# TARGET_alpha is not set
TARGET_arm=y
# TARGET_avr32 is not set
I.E. the target architecture menu is still there is menuconfig, it still saves
all the symbols it used to, but that's no longer enough. Now if you use that
menu the resulting config is completely broken. This menu used to be _the_ way
to set this stuff, and now it's still there but no longer produces a usable
.config.
The TARGET_ARCH symbol used to be set from the .config value. Now you're
setting it before the .config is even loaded.
Meanwhile, the TARGET_ARCH symbol does not show up in menuconfig. Menuconfig
loads it and saves it, but there's no way to set it from there. You never
_NEEDED_ to set it before, because its value was derived from the target
architecture symbols you can set in the target architecture menu. Now you're
setting it before .config is even loaded. You still need to use menuconfig to
set up _most_ of your configuration, and menuconfig still _claims_ to let you
set the architecture like it always did, but now you need to use a second
unrelated configuration mechanism to _actually_ set the target architecture.
This is new behavior, which was not required in the last release version, and
it is a regression.
This discussion is the first I've _ever_ heard of passing ARCH= to uClibc's
make command line, and I've been at least casually on this list for most of a
decade now. Was there a previous conversation on this I missed?
> Attached patch would use the configured ARCH for subsequent
> invocations of make(1) and not require it to be always passed down.
> Perhaps that's more what some expect.. ?
I applied the attached patch to current master, re-ran the build script that
worked just fine before 6625518cd68 went in, and it broke exactly the same way.
The patch made no difference I can tell.
Rob
--
Latency is more important than throughput. It's that simple. - Linus Torvalds
More information about the uClibc
mailing list