At Mon, 4 Oct 2004 00:25:00 +0200, Thiemo Seufer wrote: > > current mainline libgcj fails to build on mips{,el}: > > > > /home/doko/gcc/gcc-snapshot-20041003/build/gcc/xgcc -shared-libgcc > > -B/home/doko/gcc/gcc-snapshot-20041003/build/gcc/ -nostdinc++ > > -L/home/doko/gcc/gcc-snapshot-20041003/build/mipsel-linux-gnu/libstdc++-v3/src > > -L/home/doko/gcc/gcc-snapshot-20041003/build/mipsel-linux-gnu/libstdc++-v3/src/.libs > > -B/usr/lib/gcc-snapshot/mipsel-linux-gnu/bin/ > > -B/usr/lib/gcc-snapshot/mipsel-linux-gnu/lib/ -isystem > > /usr/lib/gcc-snapshot/mipsel-linux-gnu/include -isystem > > /usr/lib/gcc-snapshot/mipsel-linux-gnu/sys-include -shared -nostdlib > > /usr/lib/crti.o /home/doko/gcc/gcc-snapshot-20041003/build/gcc/crtbeginS.o > > .libs/libgcj.la-2.o -Wl,--whole-archive ../libffi/.libs/libffi_convenience.a > > ../boehm-gc/.libs/libgcjgc_convenience.a ./libltdl/.libs/libltdlc.a > > -Wl,--no-whole-archive > > -L/home/doko/gcc/gcc-snapshot-20041003/build/mipsel-linux-gnu/libstdc++-v3/src > > -L/home/doko/gcc/gcc-snapshot-20041003/build/mipsel-linux-gnu/libstdc++-v3/src/.libs > > -L/home/doko/gcc/gcc-snapshot-20041003/build/mipsel-linux-g nu/libjava ../libffi/.libs/libffi_convenience.a ../boehm-gc/.libs/libgcjgc_convenience.a -lpthread ./libltdl/.libs/libltdlc.a -ldl -lz -L/home/doko/gcc/gcc-snapshot-20041003/build/gcc -lgcc_s -lc -lgcc_s /home/doko/gcc/gcc-snapshot-20041003/build/gcc/crtendS.o /usr/lib/crtn.o -Wl,-soname -Wl,libgcj.so.6 -o .libs/libgcj.so.6.0.0 > > /usr/lib/libc_nonshared.a(atexit.oS)(.text+0x38): In function `atexit': > > : relocation truncated to fit: R_MIPS_CALL16 __cxa_atexit@@GLIBC_2.2 > > collect2: ld returned 1 exit status > > make[2]: *** [libgcj.la] Error 1 > > > > can be fixed by compiling glibc's atexit with -mxgot > > This needs _two_ sets of those objects then, because a link employing > multigot will silently break over xgot objects.
Does this problem come from glibc's compilation problem? > > (at least that's the way mozilla succeeded to build). > > Actually, no, mozilla uses the standard gcc/libc objects. It believe it > happens to work because those objects are linked in earlier, so their > GOT entry offset doesn't exceed the limit. Do you know what's the actual problem? Regards, -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]