This is the mail archive of the crossgcc@sources.redhat.com mailing list for the crossgcc project.
See the CrossGCC FAQ for lots more information.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
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
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |