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.
At Mon, 4 Oct 2004 00:25:00 +0200, 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 .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 libc_nonshared. a(atexit. oS)(.text+ 0x38): In function `atexit': @GLIBC_ 2.2
Thiemo Seufer wrote:
> > current mainline libgcj fails to build on mips{,el}:
> >
> > /home/doko/
nu/libjava ../libffi/
> > /usr/lib/
> > : relocation truncated to fit: R_MIPS_CALL16 __cxa_atexit@
> > 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