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] |
"William A. Gatliff" <bgat@billgatliff.com> wrote: > 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... An equivalent case would be when a Linux/x86 user would like to produce a toolchain which is optimized for Athlon. The built compiler binaries should be optimized for Athlon and the built glibc should be optimized too. So the configure command could be like: .../configure --build=i386-redhat-linux --host=i386-redhat-linux \ --target=i686-linux-gnu --enable-shared --enable-threads and a cross-GCC from the native plain vanilla 'i386' Linux to the 'i686-linux-gnu' target (because no default for Athlon exists) would be produced. The 'CFLAGS' used during the build must be tailored with a suitable '-march=athlon*' option too... The new cross-GCC will reside in: /usr/local/i686-linux-gnu/... and /usr/local/lib/gcc-lib/i686-linux-gnu/<gcc-version>/... because no '--prefix=' was given... If the builder in this case denies to copy the 'target headers and libs' from '/usr/include' into '/usr/local/i686-linux-gnu/include' (plus make the 'limits.h'-symlink) and copy the stuff from '/lib' and '/usr/lib' into '/usr/local/i686-linux-gnu/lib', it would be quite stupid. Just as stupid as not copying stuff for Linux/PPC from some Linux/PPC distribution when producing tools for 'powerpc-linux-gnu'. Quite similar reasons as in this Athlon-case ('i386' libs cannot be used with 'athlon-xp') may cause some misunderstandings like that 'generic' PowerPC libs cannot be used with some PPC-variant when one finally uses the built 'powerpc-linux' toolchain. This really is not the question, but whether this works during the GCC-build. As is well-known, the GCC-build needs the target headers for possible fixing and for compiling the produced libraries. And needs the target libs for linking the produced shared libraries like 'libgcc_s.so' and 'libstdc++.so'. That the 'bootstrap' C- library is for the wrong CPU-variant doesn't really matter, not in the native-GCC case, not in the cross-GCC case. If one could try to avoid using the target headers and libs in the native case by removing the stuff in '/usr/include' and '/usr/lib' so that the new GCC couldn't use them, what this could have as the result? 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. In both cases the old C-library for the target is in its place before starting. If one makes a log from a glibc-configure, one sees that the 'current glibc-headers' will be checked, so just the same 'native/update' assumptions will be used there... For the 99.9 % of the builders these really must be the cases because so few problems coming from the 'updaters' will be seen here... Cheers, Kai
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |