Bug 21206 - gcj seems not to pass the option to ld correctly
Summary: gcj seems not to pass the option to ld correctly
Status: ASSIGNED
Alias: None
Product: gcc
Classification: Unclassified
Component: java (show other bugs)
Version: 4.0.0
: P2 normal
Target Milestone: ---
Assignee: Ralf Wildenhues
URL:
Keywords: build
: 22323 22468 34097 42524 (view as bug list)
Depends on:
Blocks:
 
Reported: 2005-04-25 09:13 UTC by shan
Modified: 2011-02-13 14:47 UTC (History)
12 users (show)

See Also:
Host:
Target:
Build:
Known to work: 4.6.0
Known to fail: 4.5.3
Last reconfirmed: 2011-01-10 00:00:00


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description shan 2005-04-25 09:13:36 UTC
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
Comment 1 Andrew Pinski 2005-04-25 13:29:09 UTC
It passes correctly for me on i686-pc-linux-gnu.
Comment 2 shan 2005-04-26 00:10:59 UTC
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. 
Comment 3 Andrew Pinski 2005-07-13 19:43:48 UTC
*** Bug 22468 has been marked as a duplicate of this bug. ***
Comment 4 Andrew Pinski 2005-07-13 19:44:33 UTC
*** Bug 22323 has been marked as a duplicate of this bug. ***
Comment 5 Andrew Pinski 2005-07-13 19:46:54 UTC
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.
Comment 6 Jim Wilson 2005-07-26 23:31:47 UTC
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.
Comment 7 Rainer Emrich 2006-02-23 11:04:24 UTC
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


Comment 8 Andrew Haley 2006-02-23 13:38:59 UTC
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.
Comment 9 Rainer Emrich 2006-02-23 14:45:56 UTC
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-----
Comment 10 Andrew Haley 2006-02-23 15:41:23 UTC
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.
Comment 11 Rainer Emrich 2006-02-23 16:17:06 UTC
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

Comment 12 Jim Wilson 2006-02-24 00:49:02 UTC
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.
Comment 13 Ralf Wildenhues 2006-02-24 14:57:40 UTC
(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.
Comment 14 shan 2006-02-25 07:18:47 UTC
 > 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.
Comment 15 Andrew Pinski 2007-11-14 23:04:16 UTC
*** Bug 34097 has been marked as a duplicate of this bug. ***
Comment 16 jendog1 2007-11-14 23:16:50 UTC
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
Comment 17 Jim Wilson 2007-11-14 23:46:06 UTC
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

Comment 18 jendog1 2007-11-15 13:46:25 UTC
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


Comment 19 Poor Yorick 2009-08-17 15:16:02 UTC
I bumped into this issue with gcc-4.4.0 on x86_32 Linux, probably because I have standalone libiconv installed
Comment 20 Pierre 2009-11-07 12:24:47 UTC
I have the same problem with 4.4.2
Comment 21 Ralf Wildenhues 2011-01-10 18:39:28 UTC
*** Bug 42524 has been marked as a duplicate of this bug. ***
Comment 22 Ralf Wildenhues 2011-01-10 18:45:30 UTC
Reconfirming based on <http://gcc.gnu.org/ml/gcc/2011-01/msg00094.html>.
Comment 23 Ralf Wildenhues 2011-01-29 11:20:44 UTC
Proposed patch at: <http://gcc.gnu.org/ml/gcc-patches/2011-01/msg02172.html>
Feedback appreciated.  Thanks.
Comment 24 Ralf Wildenhues 2011-02-04 05:52:01 UTC
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