* Multilib libjava problem @ 2002-10-01 3:08 Bo Thorsen 2002-10-01 7:58 ` Libtool problem (Was: Multilib libjava problem) Bo Thorsen 0 siblings, 1 reply; 4+ messages in thread From: Bo Thorsen @ 2002-10-01 3:08 UTC (permalink / raw) To: gcc; +Cc: Andreas Jaeger I have a linking problem in libjava, trying to link the 32 bit libjava on x86-64: /bin/sh ./libtool --tag=CXX --mode=link /suse/bo/Work/gcc/build/gcc/xgcc -shared-libgcc -B/suse/bo/Work/gcc/build/gcc/ -nostdinc++ -L/suse/bo/Work/gcc/build/x86_64-unknown-linux-gnu/32/libstdc++-v3/src -L/suse/bo/Work/gcc/build/x86_64-unknown-linux-gnu/32/libstdc++-v3/src/.libs -B/usr/local/x86_64-unknown-linux-gnu/bin/ -B/usr/local/x86_64-unknown-linux-gnu/lib/ -isystem /usr/local/x86_64-unknown-linux-gnu/include -m32 -L/suse/bo/Work/gcc/build/x86_64-unknown-linux-gnu/32/libjava -ffloat-store -g -O2 -m32 -m32 -o libgcj.la -objectlist libgcj.objectlist ../boehm-gc/libgcjgc_convenience.la ../libffi/libffi_convenience.la ../zlib/libzgcj_convenience.la -rpath /usr/local/lib/32 -rpath /usr/local/lib/32 -lpthread ./libltdl/libltdlc.la -version-info `grep -v '^#' ../../../../gcc/libjava/libtool-version` creating reloadable object files... creating a temporary reloadable object file: .libs/libgcj.la-2.o /usr/bin/ld -r -o .libs/libgcj.la-1.o <aLOToffiles>.o /usr/bin/ld: Relocatable linking with relocations from format elf32-i386 (.libs/prims.o) to format elf64-x86-64 (.libs/libgcj.la-1.o) is not supported make[5]: *** [libgcj.la] Error 1 The problem here is the /usr/bin/ld command. This ought to have a -m elf_i386 switch. Does this work on other architectures with multilib? Any ideas how to fix it? Bo. -- Bo Thorsen | Praestevejen 4 Senior Software Engineer | 5290 Marslev Klarälvdalens Datakonsult | Denmark ^ permalink raw reply [flat|nested] 4+ messages in thread
* Libtool problem (Was: Multilib libjava problem) 2002-10-01 3:08 Multilib libjava problem Bo Thorsen @ 2002-10-01 7:58 ` Bo Thorsen 2002-10-01 9:23 ` Michael Matz 0 siblings, 1 reply; 4+ messages in thread From: Bo Thorsen @ 2002-10-01 7:58 UTC (permalink / raw) To: gcc On Tuesday 01 October 2002 12:08, Bo Thorsen wrote: > I have a linking problem in libjava, trying to link the 32 bit libjava on > x86-64: > > /bin/sh ./libtool --tag=CXX --mode=link /suse/bo/Work/gcc/build/gcc/xgcc > -shared-libgcc -B/suse/bo/Work/gcc/build/gcc/ -nostdinc++ > -L/suse/bo/Work/gcc/build/x86_64-unknown-linux-gnu/32/libstdc++-v3/src > -L/suse/bo/Work/gcc/build/x86_64-unknown-linux-gnu/32/libstdc++-v3/src/.lib >s -B/usr/local/x86_64-unknown-linux-gnu/bin/ > -B/usr/local/x86_64-unknown-linux-gnu/lib/ -isystem > /usr/local/x86_64-unknown-linux-gnu/include -m32 > -L/suse/bo/Work/gcc/build/x86_64-unknown-linux-gnu/32/libjava -ffloat-store > -g -O2 -m32 -m32 -o libgcj.la -objectlist libgcj.objectlist > ../boehm-gc/libgcjgc_convenience.la ../libffi/libffi_convenience.la > ../zlib/libzgcj_convenience.la -rpath /usr/local/lib/32 -rpath > /usr/local/lib/32 -lpthread ./libltdl/libltdlc.la -version-info `grep -v > '^#' ../../../../gcc/libjava/libtool-version` > > creating reloadable object files... > > creating a temporary reloadable object file: .libs/libgcj.la-2.o > > /usr/bin/ld -r -o .libs/libgcj.la-1.o <aLOToffiles>.o > > /usr/bin/ld: Relocatable linking with relocations from format elf32-i386 > (.libs/prims.o) to format elf64-x86-64 (.libs/libgcj.la-1.o) is not > supported > > make[5]: *** [libgcj.la] Error 1 > > The problem here is the /usr/bin/ld command. This ought to have a -m > elf_i386 switch. This is a libtool problem. I have come up with two different patches to try to solve this: Index: libtool.m4 =================================================================== RCS file: /cvs/gcc/gcc/libtool.m4,v retrieving revision 1.9 diff -u -r1.9 libtool.m4 --- libtool.m4 14 Aug 2002 02:39:52 -0000 1.9 +++ libtool.m4 1 Oct 2002 14:51:18 -0000 @@ -175,6 +175,19 @@ rm -rf conftest* ;; +x86_64*linux*) + # Find out which ABI we are using. + echo 'int i;' > conftest.$ac_ext + if AC_TRY_EVAL(ac_compile); then + case "`/usr/bin/file conftest.o`" in + *32-bit*) + LD="${LD-ld} -m elf_i386" + ;; + esac + fi + rm -rf conftest* + ;; + *-*-sco3.2v5*) # On SCO OpenServer 5, we need -belf to get full-featured binaries. SAVE_CFLAGS="$CFLAGS" I tried this and just running configure && make bootstrap (srcdir!=builddir) but that didn't do any change. The libtool in 32/libjava didn't have any line with x86_64 in it?? Now I'm running a test with this: Index: libtool.m4 =================================================================== RCS file: /cvs/gcc/gcc/libtool.m4,v retrieving revision 1.9 diff -u -r1.9 libtool.m4 --- libtool.m4 14 Aug 2002 02:39:52 -0000 1.9 +++ libtool.m4 1 Oct 2002 14:50:41 -0000 @@ -622,7 +622,7 @@ # This must be Linux ELF. linux-gnu*) case $host_cpu in - alpha* | hppa* | i*86 | powerpc* | sparc* | ia64* ) + alpha* | hppa* | i*86 | powerpc* | sparc* | ia64* | x86_64* ) lt_cv_deplibs_check_method=pass_all ;; *) # glibc up to 2.1.1 does not perform some relocations on ARM Is there something I have to do to make it actually use these changes? Am I completely wrong in trying this - any comments on the patches? Help! I don't know how to handle libtool. I can just see that it doesn't work as it is now. Bo. -- Bo Thorsen | Praestevejen 4 Senior Software Engineer | 5290 Marslev Klarälvdalens Datakonsult | Denmark ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Libtool problem (Was: Multilib libjava problem) 2002-10-01 7:58 ` Libtool problem (Was: Multilib libjava problem) Bo Thorsen @ 2002-10-01 9:23 ` Michael Matz 2002-10-01 11:50 ` Bo Thorsen 0 siblings, 1 reply; 4+ messages in thread From: Michael Matz @ 2002-10-01 9:23 UTC (permalink / raw) To: Bo Thorsen; +Cc: gcc Hi, On Tue, 1 Oct 2002, Bo Thorsen wrote: > This is a libtool problem. I have come up with two different patches > to try to solve this: > > +x86_64*linux*) > + # Find out which ABI we are using. > + echo 'int i;' > conftest.$ac_ext > + if AC_TRY_EVAL(ac_compile); then > + case "`/usr/bin/file conftest.o`" in > + *32-bit*) > + LD="${LD-ld} -m elf_i386" > + ;; > + esac > + fi > + rm -rf conftest* > + ;; > + > *-*-sco3.2v5*) > # On SCO OpenServer 5, we need -belf to get full-featured binaries. > SAVE_CFLAGS="$CFLAGS" > > I tried this and just running configure && make bootstrap > (srcdir!=builddir) but that didn't do any change. The libtool in > 32/libjava didn't have any line with x86_64 in it?? You need to recreate configure (in this case at least the one in libjava/) for those changes to take effect. The above change looks otherwise correct, although if you anyway touch this you can also look into KDE's libtool, which also sets $sys_lib_*search_path_spec to "/lib64 ..." or "/lib ..." depending on the current default ABI (and existance of /lib64). > Index: libtool.m4 > =================================================================== > RCS file: /cvs/gcc/gcc/libtool.m4,v > retrieving revision 1.9 > diff -u -r1.9 libtool.m4 > --- libtool.m4 14 Aug 2002 02:39:52 -0000 1.9 > +++ libtool.m4 1 Oct 2002 14:50:41 -0000 > @@ -622,7 +622,7 @@ > # This must be Linux ELF. > linux-gnu*) > case $host_cpu in > - alpha* | hppa* | i*86 | powerpc* | sparc* | ia64* ) > + alpha* | hppa* | i*86 | powerpc* | sparc* | ia64* | x86_64* ) KDE also includes "m68* | mips | mipsel | s390* | sh*". Some of them might not be tested that good, though (although in the context of KDE and linux except sh*, mipsel and m68* everything builds). Somewhen when adding the second or third of them I got the feeling the logic of that case should be inverted, but I never came around to do this ;-) Ciao, Michael. ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Libtool problem (Was: Multilib libjava problem) 2002-10-01 9:23 ` Michael Matz @ 2002-10-01 11:50 ` Bo Thorsen 0 siblings, 0 replies; 4+ messages in thread From: Bo Thorsen @ 2002-10-01 11:50 UTC (permalink / raw) To: Michael Matz, gcc On Tuesday 01 October 2002 18:23, Michael Matz wrote: > Hi, > > On Tue, 1 Oct 2002, Bo Thorsen wrote: > > This is a libtool problem. I have come up with two different patches > > to try to solve this: > > > > +x86_64*linux*) > > + # Find out which ABI we are using. > > + echo 'int i;' > conftest.$ac_ext > > + if AC_TRY_EVAL(ac_compile); then > > + case "`/usr/bin/file conftest.o`" in > > + *32-bit*) > > + LD="${LD-ld} -m elf_i386" > > + ;; > > + esac > > + fi > > + rm -rf conftest* > > + ;; > > + > > *-*-sco3.2v5*) > > # On SCO OpenServer 5, we need -belf to get full-featured binaries. > > SAVE_CFLAGS="$CFLAGS" > > > > I tried this and just running configure && make bootstrap > > (srcdir!=builddir) but that didn't do any change. The libtool in > > 32/libjava didn't have any line with x86_64 in it?? > > You need to recreate configure (in this case at least the one in libjava/) > for those changes to take effect. Yes, I figured that out and ran the full configure & bootstrap. And it worked! I'm sending a proper patch in a moment. > The above change looks otherwise > correct, although if you anyway touch this you can also look into KDE's > libtool, which also sets $sys_lib_*search_path_spec to "/lib64 ..." or > "/lib ..." depending on the current default ABI (and existance of /lib64). I see no reason for this since it's handled automatically on x86-64. > > Index: libtool.m4 > > =================================================================== > > RCS file: /cvs/gcc/gcc/libtool.m4,v > > retrieving revision 1.9 > > diff -u -r1.9 libtool.m4 > > --- libtool.m4 14 Aug 2002 02:39:52 -0000 1.9 > > +++ libtool.m4 1 Oct 2002 14:50:41 -0000 > > @@ -622,7 +622,7 @@ > > # This must be Linux ELF. > > linux-gnu*) > > case $host_cpu in > > - alpha* | hppa* | i*86 | powerpc* | sparc* | ia64* ) > > + alpha* | hppa* | i*86 | powerpc* | sparc* | ia64* | x86_64* ) > > KDE also includes "m68* | mips | mipsel | s390* | sh*". Some of them > might not be tested that good, though (although in the context of KDE and > linux except sh*, mipsel and m68* everything builds). Somewhen when > adding the second or third of them I got the feeling the logic of that > case should be inverted, but I never came around to do this ;-) I checked the cvs version of libtool, and that looks like the ones KDE uses. So GCC will get them when it upgrades to a newer libtool. Bo. -- Bo Thorsen | Praestevejen 4 Senior Software Engineer | 5290 Marslev Klarälvdalens Datakonsult | Denmark ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2002-10-01 18:30 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2002-10-01 3:08 Multilib libjava problem Bo Thorsen 2002-10-01 7:58 ` Libtool problem (Was: Multilib libjava problem) Bo Thorsen 2002-10-01 9:23 ` Michael Matz 2002-10-01 11:50 ` Bo Thorsen
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).