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] |
Hi,
I've been trying for some time now to set up gcc 3.2.3 as a cross compiler for mips-sgi-irix6 under i686-pc-linux-gnu. That is, I want a compiler that runs on Linux and gives me code for Irix 6.5. 1. Why does ld have /usr/lib32 hardcoded? (I think that might be a question for the binutils folks.)
GCC's specs contain hardcoded directories with the mips-sgi-irix6 target, ld has nothing to do with this.
2. Can someone enlighten me how I'm supposed to use --with-sysroot? I didn't get it to work (but didn't try hard, either).
It shouldn't work in gcc-3.2.3. Generally this is quite religious issue, one is either defending the cross (configuration) or then is against it... I think people on this list are defending the cross, so your question can be rather heretic ;-)
Ok, my 'bu(ll)sh(it)ism' comes here: If a system can have hundreds of cross-GCCs and only one native-GCC, should the one native GCC rule the hundreds and force these to obey its will? Or should the hundreds of cross-GCCs decide how a GCC should be installed?
Let people then call this as 'crusade' or 'defending the cross', but I will call this as 'democracy'... So, instead of trying to change cross-GCCs to be like the native-GCCs on another hosts (using '--with-sysroot'), the native GCCs could just as well be changed to obey just the same install rules as the cross-GCCs... I have never understood the important need to mimic an completely imaginary "native 'cc'" on hosts like Linux and Windows... Maybe the BSD- variants had some kind of 'pcc' ('Portable C Compiler') before GCC, so there could be some sanity in the clone-the-native-cc things...
3. Neither Irix' libc.a nor libc.so seem to be sufficient for the build;
one of them is needed for the first part, the other for the second. Why?
Not having the possibility to look inside the Irix6.5 libs, I cannot say much... Generally on MIPS/SVR4 systems like the Irixes, the usability of the '.a' libraries is unclear -- only the '.so' files should be used and everything should be in PIC-code. So I cannot understand why any '.a' files were tried as you claim...
You should make progress step-by-step, not at all like you are doing now. Suitable sane steps would be:
If this doesn't work, try adding the '-v' and '-Wl,-verbose' options to the command line and try to solve the problems... There will be many, I think...
Ok, the Irix6 configuration is only for the native GCC, and fixing the config files would be motivated -- if any Irix6 targeted cross- GCCs should be built at all. The alternative is to let it be as it is and wait for the gcc-3.4, newer binutils etc. where it should work, in order to force the cross-GCC to behave just like the native GCC, using an offset in the root directory...
Or you can manually edit the 'specs'-file for the new cross-GCC and fix the search paths to follow the cross-GCC conventions.
4. Why does the build prefer header files in `newlib/...' over the seemingly system-specific ones in `os/irix/irix6.5/'? (I tried --without-newlib once, which didn't seem to change anything.)
There are bugs in gcc-3.2.3 sources and the right C++ headers will not be symlinked, the Irix6 is not alone, Solaris2 target builders must fix the same things... And all SVR3/4-targets etc. will fail in the libstdc++-v3 configure too...
5. What's wrong with cxxabi.h, and how to I get it to continue?
Maybe the problem is in those 'fixed' C headers in your '/work/gcc-32-cross/gcc-3.2.3/gcc/include', or that these are not taken into use...
# copy Irix system headers mkdir $PREFIX/mips-sgi-irix6/sys-include rsync -avr irix-host:/usr/include/ $PREFIX/mips-sgi-irix6/sys-include
The de-facto standard for installing the target headers is the '$PREFIX/mips-sgi-irix6/include' in your case, it will be searched last just as the '/usr/include' in the native-GCC. The madness with the 'sys-include' has never achieved any understanding from me... Ok, the target headers, at least the 'limits.h' if it exists, must be seen there during the GCC-build if they should be fixed, the 'limits.h' must only be seen to exist or not... Please see the search order for the C headers in your new cross-GCC with the command:
# copy Irix libc.a rcp irix-host:/usr/lib32/cmplrs/intr32/libc.a \ $PREFIX/mips-sgi-irix6/lib
You should copy all libs below '/usr/lib32' and '/usr/lib64' into your '$PREFIX/mips-sgi-irix6/lib' and below it. The GCC 'multilib' conventions could suggest using the install dirs:
$PREFIX/mips-sgi-irix6/lib for the default/'mabi=n32' 32-bit libs from '/usr/lib32'
$PREFIX/mips-sgi-irix6/lib/mips3 for the MIPS3 optimized 32-bit libs from '/usr/lib32/mips3'
$PREFIX/mips-sgi-irix6/lib/mips4 for the MIPS4 optimized 32-bit libs from '/usr/lib32/mips4'
$PREFIX/mips-sgi-irix6/lib/n64 for the 'mabi=n64' 64-bit libs from '/usr/lib64'
$PREFIX/mips-sgi-irix6/lib/n64/mips3 for the MIPS3 optimized 64-bit libs from '/usr/lib64/mips3'
$PREFIX/mips-sgi-irix6/lib/n64/mips4 for the MIPS4 optimized 64-bit libs from '/usr/lib64/mips4'
But first the MULTILIB-settings in 'gcc/config/mips/t-iris6' should be edited to equalize the option 'mabi=n32' to the directory name 'n32', the option 'mabi=n64' to the directory name 'n64', and to add the new variations 'mips3' and 'mips4' in order to generate the MIPS3 and MIPS4 optimized 'libgcc*.a's, 'libiberty.a's and 'libstdc++.a/libstdc++.so's too... Please see the 'gcc/config/mips/t-iris6' in the sources.
Generally all that bullshit hard-coded '/usr/lib32/...' and '/usr/lib64/...' stuff could be removed from the specs both in the native and cross cases if only GCC would be allowed to use its own habits, not being forced to follow the native 'cc'... The subdirs below the '/opt/gcc/mips-sgi-irix6/lib' (or something) in the native GCC-install could simply be symlinks to the '/usr/lib32/...' and '/usr/lib64/...' stuff and no hard-coded dirs would be needed in the 'specs'.
mips-sgi-irix6/libiberty/config.log shows that ld expects crt1.o and crtn.o to live in /usr/lib32.
The 'mips-sgi-irix6-gcc' ('xgcc') gives options (via 'specs'), which state these startups from these native directories being needed...
/usr/lib32/mips3/crt1.o(.MIPS.events.text+0x10):/xlv55/kudzu-apr12/work/irix/lib/libc/libc_n32_M3/csu/crt1text.s:104: undefined reference to `__readenv_sigfpe' /usr/lib32/mips3/crt1.o(.MIPS.events.text+0x1a):/xlv55/kudzu-apr12/work/irix/lib/libc/libc_n32_M3/csu/crt1text.s:106: undefined reference to `exit' /usr/lib32/mips3/crt1.o(.MIPS.events.text+0x1c):/xlv55/kudzu-apr12/work/irix/lib/libc/libc_n32_M3/csu/crt1text.s:106: undefined reference to `exit' collect2: ld returned 1 exit status configure: failed program was:
#line 2213 "configure" #include "confdefs.h"
main(){return(0);}
I believe there are some functions in Irix libc that are only in the
shared libc.so, but not in libc.a (?). I had tried copying libc.so
instead of libc.a, but GNU ld refused to link with it. It seems that
you need both, libc.a *and* libc.so at different stages of compile. Here's what works for me:
rsync -L irix-host:/usr/lib32/mips3/libc.so $PREFIX/lib32 add as a first line to mips-sgi-irix6/config.cache: LIBS="$LIBS -L$PREFIX/lib32"
What on earth the earlier '/usr/lib32/cmplrs/intr32/libc.a' was? For me it looks like the stuff in '/usr/lib32' is the default library stuff... Ok, the 'specs' for Irix6 should tell what libs will be tried to link against, or as told, the "Hello World" compile/link test with the '-v' option will also tell these things...
/work/gcc-32-cross/mips-sgi-irix6-build/gcc/xgcc -shared-libgcc -B/work/gcc-32-cross/mips-sgi-irix6-build/gcc/ -nostdinc++ -L/work/gcc-32-cross/mips-sgi-irix6-build/mips-sgi-irix6/libstdc++-v3/src -L/work/gcc-32-cross/mips-sgi-irix6-build/mips-sgi-irix6/libstdc++-v3/src/.libs -B/work/gcc-32-irix/mips-sgi-irix6/bin/ -B/work/gcc-32-irix/mips-sgi-irix6/lib/ -isystem /work/gcc-32-irix/mips-sgi-irix6/include
As seen, the '$PREFIX/mips-sgi-irix6/include', not the '.../sys-include' is defined here. Quite schitzoprenic from the GCC-developers... If you have this de-facto install directory for the target headers now empty, the '-isystem' option doesn't do what it should -- to put this directory to be found before the other system header directories... But I think the FIXED headers from the 'sys-include' should be searched and found before these unfixed original target headers...
../../../../gcc-3.2.3/libstdc++-v3/src/vterminate.cc -DPIC -o .libs/vterminate.o In file included from ../../../../gcc-3.2.3/libstdc++-v3/src/vterminate.cc:34: ../../../../gcc-3.2.3/libstdc++-v3/libsupc++/cxxabi.h:288: syntax error before `)' token
../../../../gcc-3.2.3/libstdc++-v3/libsupc++/cxxabi.h:359: syntax error before `)' token
../../../../gcc-3.2.3/libstdc++-v3/libsupc++/cxxabi.h:408: syntax error before `)' token
Whatever headers are #included before the 'cxxabi.h' or in its beginning, they have some clashing weird definition for the '__result', or at least I would assume the error coming from this...
Unfortunately I cannot just go and download the SGI IDF and IDL stuff for Irix6.4 (shouldn't be much different from the 6.5 stuff) via the: 'http://www.sgi.com/developers/devtools/apis/idf_idl.htm' (341 MB + 317 MB), my modem connection simply disables these things as almost impossible (44 hours, 15 Mbytes/hour...). SGI doesn't send them (at no cost) on CDs :( So, if someone wants to download this stuff and burn it into a CDR and snailmail it to me in order to get at least one person more to build a RedHat Linux 7.3-to-SGI Irix 6.x cross-GCC, I wouldn't argue... That could be a very good reason to build this beast and solve the problems in the build...
------ Want more information? See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/ Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |