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