Installing headers with 0.9.29 spawns gcc errors

[Rob Landley]

On Wednesday 11 July 2007 2:33:49 am Carmelo AMOROSO wrote:
> Rob Landley wrote:
> > On Tuesday 10 July 2007 08:58:30 Carmelo AMOROSO wrote:
> >> Mike Frysinger wrote:
> >>> On Friday 18 May 2007, Yann E. MORIN wrote:
> >>>> So, to build a cross-toolchain with uClibc, we need, in order:
> >>>
> >>> no
> >>>
> >>> the only header that gets generated is bits/sysnum.h and the only thing
> >>> that uses that is syscall.h ... which gcc doesnt use, so it isnt really
> >>> too much of an issue ...
> >>
> >> Hi Mike,
> >> I'd like to come back to this issue because I've fallen in the same
> >> problem while trying to build from scratch
> >> a cross gcc (for SH4).
> >
> > Build in this order:
> >
> > Binutils, gcc, linux "make headers_install", uClibc.
> >
> > This is the same _solution_ I gave yann.  You don't need a C library to
> > build binutils or gcc.
>
> But you need the headers from whatever ?libc you have, and 'make
> headers" of uClibc, as currently work,

Can be run after you've built your cross binutils and cross gcc, and therefore 
you _have_ a cross compiler at that point.  This is what I said last message.

> try run run gcc -E CPU_FLAGS to create sysnum.h, I never said to have
> uClibc libraries to build gcc (C only).

You don't need uClibc headers to build gcc either.  I don't.  (Is this a 
requirement of some ancient version of gcc?  I'm using 4.1.2...)

> This is the issue Yann raised time ago, the same I bumped into, that I
> solved with the previous patch.

This issue can be avoided by doing things in the right order.

> The correct stage to build a cross gcc from scratch are as Mike
> reported, and works for me.
> The same approach we use to have a cross toolchain for glibc.

It's been a long time since I built a cross toolchain for glibc.  I'm under 
the vague impression that the binary object that got passed back and forth 
between glibc and gcc without ever getting rebuilt has now been fixed...

> "so the normal order is fine:

What do you mean "normal"?  It's A) broken with a project that works just fine 
for most people, B) providing something that ISN'T USED YET.

>  - build/install binutils
>  - install uClibc headers

Which aren't needed by anything yet.  You keep insisting on imposing an 
artificial constraint.  Just _skip_this_step_.

I can say it in all caps if it would help...

>  - install kernel headers
>  - build C-only gcc
>  - build/install uClibc

Which installs the headers and nothing before them has used them.

>  - build C/C++/whatever gcc
> "

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