Installing headers with 0.9.29 spawns gcc errors

[Rob Landley]

On Sunday 24 June 2007 14:34:19 Yann E. MORIN wrote:
> Hello Rob and all!
>
> On Friday 22 June 2007 07:14, Rob Landley wrote:
> > On Thursday 21 June 2007 18:30:26 Yann E. MORIN wrote:
> > > The error occurs when the target architecture is not the same as the
> > > build/host one. That is, building a i?86-unknown-linux-uclibc on a
> > > i?86-unknown-linux-{gnu,uclibc} might not be affected (although it is
> > > still buggy in an other way, imho).
> >
> > I've been doing this with my Firmware Linux build thingy for some time,
> > so there's obviously more to it than that...
>
> I've been looking quite quickly at your build scripts. Seems you do things
> in a different, if not strange, order. But see below...

It's an order that works, it's carefully arranged to minimize dependencies, 
and it took me a long time to work out. :)

> > > My setup is:
> > >  - linux-2.6.21.5's "make ARCH=i586 headers_install"
> > >  - uClibc configured for arm
> >
> > You install i586 headers and then build an arm uClibc against that?
> > How is that supposed to work at _all_?  Your linux/asm directory would be
> > all wrong.
> > ARCH=i586 plus uClibc's arch of arm: it go boing.
> > ARCH=arm and uClibc's arch of arm, that might work.
> >
> > If that was a typo, then disabling locale support is the only potential
> > point of weirdness, except that my config hasn't got locale support in it
> > either.
>
> Bah, yes: typo... I had those two x-compilers running in // and mismatched
> the copy-n-paste... Please forgive me...

Quite ok, just trying to figure out where the problem is. :)

> > The relevant section of my script is:
> > setupfor uClibc
> > make CROSS= allnoconfig KCONFIG_ALLCONFIG="${WORK}"/miniconfig-uClibc &&
> > make CROSS="${ARCH}-" KERNEL_HEADERS="${CROSS}/include"
> > PREFIX="${CROSS}/" \ RUNTIME_PREFIX=/ DEVEL_PREFIX=/ all install_runtime
> > install_dev && cd .. &&
> > $CLEANUP uClibc*
>
> Ah! You have a x-compiler at that time! How come? How did you manage to get
> a x-compiler without installing C library headers first?

Because neither binutils nor gcc need them in order to build, or even to run 
with --nostinc --nostdlib.

I build binutils first because it doesn't need anything outside itself to 
build.  (It needs a working host toolchain of course, but no other target 
packages.)

Then I build gcc, because the only target package it depends on is the 
appropriate cross-binutils.

Then I compensate for the fact that gcc's path logic is DEEPLY BROKEN with a 
wrapper script and moving paths around and generally hitting the sucker with 
a large rock for being STUPID.

Then I get around to installing the kernel headers because uClibc needs them 
(nothing before this did), and then I build uClibc which needs all of the 
above.

That's why I do that stuff in that order.  I could install kernel headers 
earlier (they're self contained and don't need any other target package 
either), but if I did that people looking at my script might assume that gcc 
and binutils need them, which they don't.

> > They're not doing it for me now.  I'd like to reproduce the problem
> > before endorsing a solution.
>
> Agreed you want to reproduce. But you can't, as you don't use the same,
> somewhat traditional sequence as I do :
>  - kernel headers
>  - binutils

If binutils doesn't use the kernel headers, why install them first?

>  - C library headers   <-- error happens here: I don't have a x-compiler
> yet! - core compiler

You don't need the C library headers in order to build the cross compiler.  
Honestly, you don't.

>  - C library full
>  - final compiler

So you're arguing in favor of an order that doesn't work because 
it's "traditional"?

The compiler links stuff against the C library when you run the compiler, but 
not when you _build_ the compiler.  Don't confuse the requirements for 
running a program with the requirements for compiling that program.  Building 
uClibc requires a cross compiler, but building a cross compiler does not 
require either a target C library or the target library's headers, those can 
be installed afterwards.

Separating the "C library headers" from the "C library full" when they come 
from the same source page and get done one right after another seems a bit... 
odd.  This is two steps?

I'm giving a tutorial about all this at OLS on Thursday, by the way:
http://www.linuxsymposium.org/2007/view_abstract.php?content_key=3

Rob
-- 
"One of my most productive days was throwing away 1000 lines of code."
  - Ken Thompson.