Trying to set up gcc 3.2.3 cross i686-linux -> mips-sgi-irix6

Wed May 7 19:16:00 GMT 2003

Alexander JOLK wrote:

> 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:

1.  Build GCC first using the 'make all-gcc'

2.  Then install GCC using the 'make install-gcc'

3.  Then try compiling and linking a "Hello World":

       mips-sgi-irix6-gcc -o hello hello.c

     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:

   /work/gcc-32-cross/gcc-3.2.3/gcc/cpp -v

> # 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

Line 288:                   __upcast_result &__restrict __result) const;

> ../../../../gcc-3.2.3/libstdc++-v3/libsupc++/cxxabi.h:359: syntax error
> before `)' token

Line 359:                   __upcast_result &__restrict __result) const;

> ../../../../gcc-3.2.3/libstdc++-v3/libsupc++/cxxabi.h:408: syntax error
> before `)' token

Line 408:                   __upcast_result &__restrict __result) const;

  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...

Cheers, Kai

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