Problem building cross-gcc for powerpc-linux

[William A. Gatliff]

Kai:


> > I've been looking at the problems in libgcc2.c, they're the ones that
> > make the ppc-linux target impossible to bootstrap.  No obvious fixes
> > in mind yet, unfortunately.
> 
> As people surely remember, I have considered these problems being
> only "attitude problems" and people can blame themselves if wanting
> to struggle with them...
>
> Meanwhile the people who build a 'powerpc-linux' target GCC in the
> native Linux/PPC platform, have the 'target headers and libraries'
> in their expected places ('/usr/include' and '/usr/lib' plus '/lib'
> there), some cross-GCC builders building for this same target will
> continuously try to avoid installing any 'target headers and libs'
> before starting to build their GCCs, whatever problems this will
> cause them... Do the Linux/PPC-developers care ?  Of course not,
> stupidity is always stupidity and when the GCC-manual tells that
> those headers and libs must be there and people don't believe,
> what one can then do than let them try their tricks...

I appreciate your understanding, Kai, really.  But I run PPC, ARM,
MIPS, 68K, and SH cross compilers (yes all of them, I'm not being
hypothetical) on my X86 workstation.  Where the f%!k am I going to get
a GNU-powered ARM, MIPS, 68K or SH workstation to copy header files
from?

That's right, I'm _not_.  And saying that the fact that I'm not going
to go workstation-shopping every time a new client comes in the door
is some kind of "attitude problem" is, frankly, kind of insulting.

> As is well-known, the GCC-build needs the target headers for
> possible fixing and for compiling the produced libraries.

Gcc could manage just fine without them in the 2.95.x days, at least
through the bootstrap phase.  And that was good enough to build the
right header files for a complete compiler.  The process was
technically sound, the procedure was technically sound, and it all
really made sense when you thought the whole thing through.

Now don't get me wrong, I'm not at all unhappy with the current
situation for 3.x bootstrapping.  I think gcc-3.x is simply awesome,
although it has a few kinks to work out yet--- one of which being
bootstrapping.  Only a small percentage of gcc users bootstrap anyway,
I don't mind being left out for a while.  And I certainly don't mind
helping out by suggesting or crafting a proper solution if I can find
a good one.

In the meantime, a not-so-bad alternative is to bootstrap a 2.95.x
gcc, use it to build headers for the proper target, then use those
headers to build the 3.x system.  I can live with that for now.  But
my preference would be for the 3.x system to be bootstrap-able.

> The defaults for builds in the GCC sources are the native case
> ('update the current GCC' or 'make an alternative for the 'cc')
> and 'update the current GCC' in the cross-GCC case.

I don't see a singular, all-encompassing requirement for this.

In fact, if we accept this then we tie ourselves to 2.95.x forever,
since it's the only one that can start a gcc setup process on a virgin
workstation.  Is that what you are proposing?  For the sake of gcc
itself, I hope not!



b.g.
-- 
Bill Gatliff
Professional embedded GNU training.
http://billgatliff.com

------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com