On Solaris 9 (x86) with gcc-4.0.0 and binutils-2.15, mkdir GCC_OBJ cd GCC_OBJ ../gcc4.0.0/configure --with-gnu-ld make gives us the following errors: /hoge/gcc/GCC_OBJ/gcc/gcj -B/hoge/gcc/GC C_OBJ/gcc/ -B/usr/local/i386-pc-solaris2.9/bin/ -B/usr/local/i386-pc-solaris2.9/ lib/ -isystem /usr/local/i386-pc-solaris2.9/include -isystem /usr/local/i386-pc- solaris2.9/sys-include -ffloat-store -fno-omit-frame-pointer -g -O2 -o .libs/jv- convert --main=gnu.gcj.convert.Convert -shared-libgcc -L/export/home/yamasaki/s ys/gcc/GCC_OBJ/i386-pc-solaris2.9/libjava -L/hoge/gcc/GCC_OB J/i386-pc-solaris2.9/libjava/.libs ./.libs/libgcj.so -L/hoge /gcc/GCC_OBJ/i386-pc-solaris2.9/libstdc++-v3/src -L/hoge/gcc /GCC_OBJ/i386-pc-solaris2.9/libstdc++-v3/src/.libs -lpthread -lrt -ldl -L/export /home/yamasaki/sys/gcc/GCC_OBJ/gcc -L/usr/local/i386-pc-solaris2.9/bin -L/usr/lo cal/i386-pc-solaris2.9/lib -L/usr/local/lib/gcc/i386-pc-solaris2.9/../../../i386 -pc-solaris2.9/lib -L/usr/ccs/bin -L/usr/ccs/lib -L/usr/local/lib/gcc/i386-pc-so laris2.9/../.. -lgcc_s -lgcc_s -Wl,--rpath -Wl,/usr/local/lib /usr/local/i386-pc-solaris2.9/bin/ld: unrecognized option '-Wl,-rpath' /usr/local/i386-pc-solaris2.9/bin/ld: use the --help option for usage informatio n collect2: ld returned 1 exit status make[2]: *** [jv-convert] Error 1 make[2]: Leaving directory `/hoge/gcc/GCC_OBJ/i386-pc-solari s2.9/libjava' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/hoge/gcc/GCC_OBJ/i386-pc-solari s2.9/libjava' make: *** [all-target-libjava] Error 2
It passes correctly for me on i686-pc-linux-gnu.
Sure I also confirmed it working on i686-pc-linux-gnu (SuSE 9.2). So this must be specific to i386-pc-solaris2.9. Thanks in advance.
*** Bug 22468 has been marked as a duplicate of this bug. ***
*** Bug 22323 has been marked as a duplicate of this bug. ***
Hmm, since this has now reported on i686-pc-linux-gnu, I have no idea what is going on. The only thing I can think of is gcj is being miss compiled but I really doubt that since this also on sparc too.
I saw this problem on an x86-freebsd machine yesterday. The problem is that $target/libjava/libgcj.spec has this *lib: -lgcj -lm /usr/local/lib/libiconv.so -Wl,-rpath -Wl,/usr/local/lib %{!pthread: %{!shared: %eUnder this configuration, the user must provide -pthread when linking.}} %(libgcc) %(liborig) This causes the strange ld error. The underlying problem seems to be that I have a copy of libiconv in /usr/local/lib. The Makefile has this line LIBICONV = /usr/local/lib/libiconv.so -Wl,-rpath -Wl,/usr/local/lib libgcj.spec is built from libgcj.spec.in, which causes LIBICONV to be substituted into the lib spec. And now we have gcc options (-Wl) in a linker spec (lib), which doesn't work. I didn't look for a solution. I just fixed it by hand. When your libjava build fails, edit the $target/libjava/libgcj.spec file to delete both spurious instances of "-Wl,", continue the build, and this time it will finish successfully. However, I did then get a lot of libjava failures, but I didn't care about them at the time, so I ignored them. I don't know if they are related to this issue, or whether it was a temporary snapshot instability problem.
Subject: Re: gcj seems not to pass the option to ld correctly The config.log in libjava has two entries for libiconv: LIBICONV which is LIBICONV='/appl/shared/gnu/Linux/ia64-unknown-linux-gnu/lib/libiconv.so -Wl,-rpath -Wl,/appl/shared/gnu/Linux/ia64-unknown-linux-gnu/lib' in my case. The second is LTLIBICONV which is LTLIBICONV='-L/appl/shared/gnu/Linux/ia64-unknown-linux-gnu/lib -liconv -R/appl/shared/gnu/Linux/ia64-unknown-linux-gnu/lib' in my case. I changed the libgcj.spec file manually to the second. That seems to work. So, my conclusion is to change the libgcj.spec.in. The following line: *lib: -lgcj -lm @LIBICONV@ @GCSPEC@ @THREADSPEC@ @ZLIBSPEC@ @SYSTEMSPEC@ %(libgcc) %(liborig) should be changed to *lib: -lgcj -lm @LTLIBICONV@ @GCSPEC@ @THREADSPEC@ @ZLIBSPEC@ @SYSTEMSPEC@ %(libgcc) %(liborig) Any comments? Rainer P.S.: In the mean time I try to do a complete bootstrap and testsuite run
Subject: Re: Re: gcj seems not to pass the option to ld correctly Rainer Emrich writes: > The config.log in libjava has two entries for libiconv: > LIBICONV > which is > LIBICONV='/appl/shared/gnu/Linux/ia64-unknown-linux-gnu/lib/libiconv.so > -Wl,-rpath -Wl,/appl/shared/gnu/Linux/ia64-unknown-linux-gnu/lib' > in my case. > > The second is > LTLIBICONV > which is > LTLIBICONV='-L/appl/shared/gnu/Linux/ia64-unknown-linux-gnu/lib -liconv > -R/appl/shared/gnu/Linux/ia64-unknown-linux-gnu/lib' > in my case. > > I changed the libgcj.spec file manually to the second. That seems to work. > So, my conclusion is to change the libgcj.spec.in. > The following line: > *lib: -lgcj -lm @LIBICONV@ @GCSPEC@ @THREADSPEC@ @ZLIBSPEC@ @SYSTEMSPEC@ > %(libgcc) %(liborig) > should be changed to > *lib: -lgcj -lm @LTLIBICONV@ @GCSPEC@ @THREADSPEC@ @ZLIBSPEC@ @SYSTEMSPEC@ > %(libgcc) %(liborig) > > Any comments? Looks right to me. BTW, what failure caused you to find this? Andrew.
Subject: Re: gcj seems not to pass the option to ld correctly -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Andrew Haley schrieb: > Rainer Emrich writes: > > The config.log in libjava has two entries for libiconv: > > LIBICONV > > which is > > LIBICONV='/appl/shared/gnu/Linux/ia64-unknown-linux-gnu/lib/libiconv.so > > -Wl,-rpath -Wl,/appl/shared/gnu/Linux/ia64-unknown-linux-gnu/lib' > > in my case. > > > > The second is > > LTLIBICONV > > which is > > LTLIBICONV='-L/appl/shared/gnu/Linux/ia64-unknown-linux-gnu/lib -liconv > > -R/appl/shared/gnu/Linux/ia64-unknown-linux-gnu/lib' > > in my case. > > > > I changed the libgcj.spec file manually to the second. That seems to work. > > So, my conclusion is to change the libgcj.spec.in. > > The following line: > > *lib: -lgcj -lm @LIBICONV@ @GCSPEC@ @THREADSPEC@ @ZLIBSPEC@ @SYSTEMSPEC@ > > %(libgcc) %(liborig) > > should be changed to > > *lib: -lgcj -lm @LTLIBICONV@ @GCSPEC@ @THREADSPEC@ @ZLIBSPEC@ @SYSTEMSPEC@ > > %(libgcc) %(liborig) > > > > Any comments? > > Looks right to me. BTW, what failure caused you to find this? > > Andrew. See the following messages: http://gcc.gnu.org/ml/gcc/2006-02/msg00415.html http://gcc.gnu.org/ml/gcc/2006-02/msg00482.html Rainer - -- Rainer Emrich TECOSIM GmbH Im Eichsfeld 3 65428 Rüsselsheim Phone: +49(0)6142/8272 12 Mobile: +49(0)163/56 949 20 Fax.: +49(0)6142/8272 49 Web: www.tecosim.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFD/cqY3s6elE6CYeURAotyAJ9rjAZSd2y1VN02UAHwcNvS4+YtQACdHPyZ j7k/mmCAQ9I8NkS3VgLA8Jo= =62eW -----END PGP SIGNATURE-----
Subject: Re: gcj seems not to pass the option to ld correctly Rainer Emrich writes: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Andrew Haley schrieb: > > Rainer Emrich writes: > > > The config.log in libjava has two entries for libiconv: > > > LIBICONV > > > which is > > > LIBICONV='/appl/shared/gnu/Linux/ia64-unknown-linux-gnu/lib/libiconv.so > > > -Wl,-rpath -Wl,/appl/shared/gnu/Linux/ia64-unknown-linux-gnu/lib' > > > in my case. > > > > > > The second is > > > LTLIBICONV > > > which is > > > LTLIBICONV='-L/appl/shared/gnu/Linux/ia64-unknown-linux-gnu/lib -liconv > > > -R/appl/shared/gnu/Linux/ia64-unknown-linux-gnu/lib' > > > in my case. > > > > > > I changed the libgcj.spec file manually to the second. That seems to work. > > > So, my conclusion is to change the libgcj.spec.in. > > > The following line: > > > *lib: -lgcj -lm @LIBICONV@ @GCSPEC@ @THREADSPEC@ @ZLIBSPEC@ @SYSTEMSPEC@ > > > %(libgcc) %(liborig) > > > should be changed to > > > *lib: -lgcj -lm @LTLIBICONV@ @GCSPEC@ @THREADSPEC@ @ZLIBSPEC@ @SYSTEMSPEC@ > > > %(libgcc) %(liborig) > > > > > > Any comments? > > > > Looks right to me. BTW, what failure caused you to find this? > See the following messages: > > http://gcc.gnu.org/ml/gcc/2006-02/msg00415.html > http://gcc.gnu.org/ml/gcc/2006-02/msg00482.html Yes, I agree with your reasoning. AFAIK Mark Mitchell has to approve this as it's for the release, but it's OK by me if it passes bootstrap. I don't see this problem on my system because LIBICONV and LTLIBICONV are both null. AFAIK that's because iconv is in libc. Andrew.
Subject: Re: gcj seems not to pass the option to ld correctly Andrew Haley schrieb: > Rainer Emrich writes: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > Andrew Haley schrieb: > > > Rainer Emrich writes: > > > > The config.log in libjava has two entries for libiconv: > > > > LIBICONV > > > > which is > > > > LIBICONV='/appl/shared/gnu/Linux/ia64-unknown-linux-gnu/lib/libiconv.so > > > > -Wl,-rpath -Wl,/appl/shared/gnu/Linux/ia64-unknown-linux-gnu/lib' > > > > in my case. > > > > > > > > The second is > > > > LTLIBICONV > > > > which is > > > > LTLIBICONV='-L/appl/shared/gnu/Linux/ia64-unknown-linux-gnu/lib -liconv > > > > -R/appl/shared/gnu/Linux/ia64-unknown-linux-gnu/lib' > > > > in my case. > > > > > > > > I changed the libgcj.spec file manually to the second. That seems to work. > > > > So, my conclusion is to change the libgcj.spec.in. > > > > The following line: > > > > *lib: -lgcj -lm @LIBICONV@ @GCSPEC@ @THREADSPEC@ @ZLIBSPEC@ @SYSTEMSPEC@ > > > > %(libgcc) %(liborig) > > > > should be changed to > > > > *lib: -lgcj -lm @LTLIBICONV@ @GCSPEC@ @THREADSPEC@ @ZLIBSPEC@ @SYSTEMSPEC@ > > > > %(libgcc) %(liborig) > > > > > > > > Any comments? > > > > > > Looks right to me. BTW, what failure caused you to find this? > > > See the following messages: > > > > http://gcc.gnu.org/ml/gcc/2006-02/msg00415.html > > http://gcc.gnu.org/ml/gcc/2006-02/msg00482.html > > Yes, I agree with your reasoning. AFAIK Mark Mitchell has to approve > this as it's for the release, but it's OK by me if it passes > bootstrap. > > I don't see this problem on my system because LIBICONV and LTLIBICONV > are both null. AFAIK that's because iconv is in libc. > > Andrew. Bootstrap passed at my site for ia64-unknown-linux-gnu. Testsuite run for libjaava gives: === libjava Summary === # of expected passes 4009 # of unexpected failures 1 # of expected failures 10 # of untested testcases 8 Rainer
It appears that the LT stands for libtool. So the first one (LIBICONV) is supposed to be used for linking if you aren't using libtool, and the second one (LTLIBICONV) is used for linking if you are using libtool. It is a happy accident that libtool is using linker options, where the non-libtool one is using gcc options. Misusing libtool support this way probably isn't the best possible solution, but it does look to me like it will work fine. So, yes, this looks OK to me. We could at least get this on mainline even if we can't fix the release branches yet.
(In reply to comment #12) > It appears that the LT stands for libtool. So the first one (LIBICONV) is > supposed to be used for linking if you aren't using libtool, and the second one > (LTLIBICONV) is used for linking if you are using libtool. Right. You cannot expect to be able to use $LTLIBICONV if you are not using Libtool. > So, yes, this looks OK to me. We could at least get this on mainline even if > we can't fix the release branches yet. That is not ok. Best would probably be if you took LIBICONV and killed all instances of $wl aka $acl_cv_wl from it, and turned all remaining comma into spaces, for good measure. I think. For the former, you could also call AC_LIB_RPATH explicitly and unset or empty $wl for the AM_ICONV call, and restore it afterwards. If you don't need the LIBICONV for other purposes that may involve linking with a compiler driver. Or fix config/lib-link.m4 AC_LIB_RPATH to provide additional variables for use when linking with $LD. Luckily newer Libtool macros don't do that very often anymore, so it may not be worth it.
> I changed the libgcj.spec file manually to the second. That seems to work. > So, my conclusion is to change the libgcj.spec.in. > The following line: > *lib: -lgcj -lm @LIBICONV@ @GCSPEC@ @THREADSPEC@ @ZLIBSPEC@ @SYSTEMSPEC@ > %(libgcc) %(liborig) > should be changed to > *lib: -lgcj -lm @LTLIBICONV@ @GCSPEC@ @THREADSPEC@ @ZLIBSPEC@ @SYSTEMSPEC@ > %(libgcc) %(liborig) I am the original poster. Make is succeeded after this fix on Solaris 9 (x86). Thank yor for you support.
*** Bug 34097 has been marked as a duplicate of this bug. ***
i'm receiving a very similar error under solaris 2.10, binutils and core utils (latest versions), gnu make, etc. gcc 4.1.2 built fine ... gcc 4.2.1 and 4.2.2 fail with the same error below ... /usr/bin/ksh ./libtool --tag=CXX --mode=link /apps/tmp/./gcc/xgcc -shared-libgcc -B/apps/tmp/./gcc -nostdinc++ -L/apps/tmp/sparc-sun-solaris2.10/libstdc++-v3/src -L/apps/tmp/sparc-sun-solaris2.10/libstdc++-v3/src/.libs -B/usr/local/sparc-sun-solaris2.10/bin/ -B/usr/local/sparc-sun-solaris2.10/lib/ -isystem /usr/local/sparc-sun-solaris2.10/include -isystem /usr/local/sparc-sun-solaris2.10/sys-include -L/apps/tmp/sparc-sun-solaris2.10/libjava -g -O2 -o libgcj-tools.la -rpath /usr/local/lib -rpath /usr/local/lib -version-info `grep -v '^#' ../../gcc-4.2.2/libjava/libtool-version` classpath/tools/libgcj_tools_la-tools.lo /apps/tmp/./gcc/xgcc -shared-libgcc -B/apps/tmp/./gcc -nostdinc++ -L/apps/tmp/sparc-sun-solaris2.10/libstdc++-v3/src -L/apps/tmp/sparc-sun-solaris2.10/libstdc++-v3/src/.libs -B/usr/local/sparc-sun-solaris2.10/bin/ -B/usr/local/sparc-sun-solaris2.10/lib/ -isystem /usr/local/sparc-sun-solaris2.10/include -isystem /usr/local/sparc-sun-solaris2.10/sys-include -shared -nostdlib /apps/tmp/./gcc/crti.o /usr/ccs/lib/values-Xa.o /apps/tmp/./gcc/crtbegin.o classpath/tools/.libs/libgcj_tools_la-tools.o -L/apps/tmp/sparc-sun-solaris2.10/libstdc++-v3/src -L/apps/tmp/sparc-sun-solaris2.10/libstdc++-v3/src/.libs -L/apps/tmp/sparc-sun-solaris2.10/libjava -L/apps/tmp/./gcc -L/usr/local/sparc-sun-solaris2.10/bin -L/usr/local/sparc-sun-solaris2.10/lib -L/usr/local/lib/gcc/sparc-sun-solaris2.10/../../../sparc-sun-solaris2.10/lib -L/usr/ccs/lib -L/usr/local/lib/gcc/sparc-sun-solaris2.10/../.. -lgcc_s -lgcc_s -lc /apps/tmp/./gcc/crtend.o /apps/tmp/./gcc/crtn.o -Wl,-soname -Wl,libgcj-tools.so.8 -o .libs/libgcj-tools.so.8.0.0 (cd .libs && rm -f libgcj-tools.so.8 && ln -s libgcj-tools.so.8.0.0 libgcj-tools.so.8) (cd .libs && rm -f libgcj-tools.so && ln -s libgcj-tools.so.8.0.0 libgcj-tools.so) /usr/local/sparc-sun-solaris2.10/bin/ar rc .libs/libgcj-tools.a classpath/tools/libgcj_tools_la-tools.o /usr/local/sparc-sun-solaris2.10/bin/ranlib .libs/libgcj-tools.a creating libgcj-tools.la (cd .libs && rm -f libgcj-tools.la && ln -s ../libgcj-tools.la libgcj-tools.la) /usr/bin/ksh ./libtool --tag=GCJ --mode=link /apps/tmp/gcc/gcj -B/apps/tmp/sparc-sun-solaris2.10/libjava/ -B/apps/tmp/gcc/ -L/apps/tmp/sparc-sun-solaris2.10/libjava -g -O2 -o jv-convert --main=gnu.gcj.convert.Convert -rpath /usr/local/lib -shared-libgcc -L/apps/tmp/sparc-sun-solaris2.10/libjava/.libs libgcj.la /apps/tmp/gcc/gcj -B/apps/tmp/sparc-sun-solaris2.10/libjava/ -B/apps/tmp/gcc/ -g -O2 -o .libs/jv-convert --main=gnu.gcj.convert.Convert -shared-libgcc -L/apps/tmp/sparc-sun-solaris2.10/libjava -L/apps/tmp/sparc-sun-solaris2.10/libjava/.libs ./.libs/libgcj.so -L/apps/tmp/sparc-sun-solaris2.10/libstdc++-v3/src -L/apps/tmp/sparc-sun-solaris2.10/libstdc++-v3/src/.libs -lpthread -lrt -ldl -L/apps/tmp/./gcc -L/usr/local/sparc-sun-solaris2.10/bin -L/usr/local/sparc-sun-solaris2.10/lib -L/usr/local/lib/gcc/sparc-sun-solaris2.10/../../../sparc-sun-solaris2.10/lib -L/usr/ccs/lib -L/usr/local/lib/gcc/sparc-sun-solaris2.10/../.. -lgcc_s -lgcc_s -Wl,--rpath -Wl,/usr/local/lib /usr/local/sparc-sun-solaris2.10/bin/ld: unrecognized option '-Wl,-rpath' /usr/local/sparc-sun-solaris2.10/bin/ld: use the --help option for usage information collect2: ld returned 1 exit status make[3]: *** [jv-convert] Error 1 make[3]: Leaving directory `/apps/tmp/sparc-sun-solaris2.10/libjava' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/apps/tmp/sparc-sun-solaris2.10/libjava' make[1]: *** [all-target-libjava] Error 2 make[1]: Leaving directory `/apps/tmp' make: *** [all] Error 2
Subject: Re: gcj seems not to pass the option to ld correctly On Wed, 2007-11-14 at 23:16 +0000, tom_francen at midtechcorp dot com wrote: > i'm receiving a very similar error under solaris 2.10, binutils and core utils > (latest versions), gnu make, etc. gcc 4.1.2 built fine ... gcc 4.2.1 and 4.2.2 > fail with the same error below ... You can try the workaround I gave in comment #6. Jim
Subject: Re: gcj seems not to pass the option to ld correctly thank you wilson ... i just tried suggestion #6 ... and it WORKED!! thank you very much!! tjf ------------------- Thomas James Francen Midwest Technologies Corporation http://www.midtechcorp.com - website +1.303.898.6300 - Cell / Voicemail +1.610.887.5155 - Fax --- gcc-bugzilla@gcc.gnu.org wrote: From: "wilson at tuliptree dot org" <gcc-bugzilla@gcc.gnu.org> To: tom_francen@midtechcorp.com Subject: [Bug java/21206] gcj seems not to pass the option to ld correctly Date: 14 Nov 2007 23:46:07 -0000 ------- Comment #17 from wilson at tuliptree dot org 2007-11-14 23:46 ------- Subject: Re: gcj seems not to pass the option to ld correctly On Wed, 2007-11-14 at 23:16 +0000, tom_francen at midtechcorp dot com wrote: > i'm receiving a very similar error under solaris 2.10, binutils and core utils > (latest versions), gnu make, etc. gcc 4.1.2 built fine ... gcc 4.2.1 and 4.2.2 > fail with the same error below ... You can try the workaround I gave in comment #6. Jim
I bumped into this issue with gcc-4.4.0 on x86_32 Linux, probably because I have standalone libiconv installed
I have the same problem with 4.4.2
*** Bug 42524 has been marked as a duplicate of this bug. ***
Reconfirming based on <http://gcc.gnu.org/ml/gcc/2011-01/msg00094.html>.
Proposed patch at: <http://gcc.gnu.org/ml/gcc-patches/2011-01/msg02172.html> Feedback appreciated. Thanks.
Author: rwild Date: Fri Feb 4 05:51:57 2011 New Revision: 169822 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169822 Log: Fix PR java/21206: Unrecognized option '-Wl,-rpath' for jv-convert libjava/: PR java/21206 * configure.ac (LDLIBICONV): New substituted variable, with instances of '-Wl,' removed from LIBICONV. * configure: Regenerate. * libgcj.spec.in: Use @LDLIBICONV@ not @LIBICONV@. * Makefile.in: Regenerate. * gcj/Makefile.in: Likewise. * include/Makefile.in: Likewise. * testsuite/Makefile.in: Likewise. Modified: trunk/libjava/ChangeLog trunk/libjava/Makefile.in trunk/libjava/configure trunk/libjava/configure.ac trunk/libjava/gcj/Makefile.in trunk/libjava/include/Makefile.in trunk/libjava/libgcj.spec.in trunk/libjava/testsuite/Makefile.in
Closing as won't fix as the Java front-end has been removed from the trunk.