Bug 40947 - Invalid flag usage: Wl,-rpath, -Wx,-option must appear after -_SYSTYPE_SVR4
Summary: Invalid flag usage: Wl,-rpath, -Wx,-option must appear after -_SYSTYPE_SVR4
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: libgcj (show other bugs)
Version: 4.5.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-08-03 08:55 UTC by Hin-Tak Leung
Modified: 2012-09-10 21:20 UTC (History)
4 users (show)

See Also:
Host: alphaev68-dec-osf5.1a
Target:
Build:
Known to work: 4.6.0, 4.6.1, 4.6.2, 4.6.3, 4.7.0, 4.7.1
Known to fail: 4.3.3, 4.3.4, 4.3.5, 4.3.6, 4.4.1, 4.4.4, 4.4.5, 4.4.6, 4.4.7, 4.5.0, 4.5.1, 4.5.2, 4.5.3, 4.5.4
Last reconfirmed:


Attachments
alphaev68-dec-osf5.1a/libjava/config.log from 4.4.5 (19.38 KB, text/plain)
2010-12-16 00:22 UTC, Hin-Tak Leung
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Hin-Tak Leung 2009-08-03 08:55:52 UTC
svn r150353 - snapshot a few days ago: This is probably quite obvious and easy to fix? I couldn't work out the syntax of -_SYSTYPE_SVR4...

-------------------------
make[3]: Entering directory `/home/htl10/tmp-build/g-svn/alphaev68-dec-osf5.1a/libjava'
/usr/local/bin/bash ./libtool --tag=GCJ --mode=link /home/htl10/tmp-build/g-svn/./gcc/gcj -B/home/htl10/tmp-build/g-svn/alphaev68-dec-osf5.1a/libjava/ -B/home/htl10/tmp-build/g-svn/./gcc/ -B/usr/local/alphaev68-dec-osf5.1a/bin/ -B/usr/local/alphaev68-dec-osf5.1a/lib/ -isystem /usr/local/alphaev68-dec-osf5.1a/include -isystem /usr/local/alphaev68-dec-osf5.1a/sys-include    -L/home/htl10/tmp-build/g-svn/alphaev68-dec-osf5.1a/libjava -mieee -g -O2  -o jv-convert --main=gnu.gcj.convert.Convert -rpath /usr/local/lib -shared-libgcc    -L/home/htl10/tmp-build/g-svn/alphaev68-dec-osf5.1a/libjava/.libs libgcj.la 
libtool: link: /home/htl10/tmp-build/g-svn/./gcc/gcj -B/home/htl10/tmp-build/g-svn/alphaev68-dec-osf5.1a/libjava/ -B/home/htl10/tmp-build/g-svn/./gcc/ -B/usr/local/alphaev68-dec-osf5.1a/bin/ -B/usr/local/alphaev68-dec-osf5.1a/lib/ -isystem /usr/local/alphaev68-dec-osf5.1a/include -isystem /usr/local/alphaev68-dec-osf5.1a/sys-include -mieee -g -O2 -o .libs/jv-convert --main=gnu.gcj.convert.Convert -shared-libgcc  -L/home/htl10/tmp-build/g-svn/alphaev68-dec-osf5.1a/libjava/.libs -L/home/htl10/tmp-build/g-svn/alphaev68-dec-osf5.1a/libjava ./.libs/libgcj.so -lpthread -lrt -Wl,-rpath -Wl,/usr/local/lib
/bin/ld:
Invalid flag usage: Wl,-rpath, -Wx,-option must appear after -_SYSTYPE_SVR4 
/bin/ld: Usage: /bin/ld [options] file [...]
collect2: ld returned 1 exit status
make[3]: *** [jv-convert] Error 1
make[3]: Leaving directory `/home/htl10/tmp-build/g-svn/alphaev68-dec-osf5.1a/libjava'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/home/htl10/tmp-build/g-svn/alphaev68-dec-osf5.1a/libjava'
make[1]: *** [all-target-libjava] Error 2
make[1]: Leaving directory `/home/htl10/tmp-build/g-svn'
make: *** [all] Error 2
-------------------------
Comment 1 Hin-Tak Leung 2009-08-03 08:57:38 UTC
This is just from ../src/configure ; make .
Comment 2 Hin-Tak Leung 2010-07-14 10:05:53 UTC
This seems to have become an regression - it worked in 4.3.3 and failed in 4.3.5 .
Comment 3 Hin-Tak Leung 2010-07-15 21:29:16 UTC
Adding a few releases I have tried (4.3.4, 4.3.5, 4.4.4 and 4.5.0 all failed), and 4.4.1 worked.

I can try 4.4.2 and 4.4.3 as well if somebody insists.
Comment 4 Hin-Tak Leung 2010-12-15 14:57:27 UTC
Still same problem with 4.4.5. (haven't tried 4.5.1 since it is still affected by bug 44959).
Comment 5 Ralf Wildenhues 2010-12-15 19:23:05 UTC
Can you attach alphaev68-dec-osf5.1a/libjava/config.log for this failure please?
Thanks.
Comment 6 Hin-Tak Leung 2010-12-16 00:22:07 UTC
Created attachment 22778 [details]
alphaev68-dec-osf5.1a/libjava/config.log from 4.4.5

4.4.5,  alphaev68-dec-osf5.1a/libjava/config.log
from
CONFIG_SHELL=/usr/local/bin/bash ../gcc-4.4.5/configure && \
CONFIG_SHELL=/usr/local/bin/bash /usr/localbin/make

(/usr/local/bin/make is GNU make, system make isn't suitable for gcc - known problem)

I'll keep the build tree for a while in case something else is needed.
Comment 7 Hin-Tak Leung 2010-12-16 00:23:11 UTC
known to fail with 4.4.5.
Comment 8 Hin-Tak Leung 2011-04-30 18:59:41 UTC
4.4.6 also fails.
Comment 9 Hin-Tak Leung 2011-04-30 19:01:44 UTC
The last part of the 4.4.6 failure:
--------------
libtool: link: (cd ".libs" && rm -f "libgcj-tools.so.10" && ln -s "libgcj-tools.so.10.0.0" "libgcj-tools.so.10")
libtool: link: (cd ".libs" && rm -f "libgcj-tools.so" && ln -s "libgcj-tools.so.10.0.0" "libgcj-tools.so")
libtool: link: /usr/local/alphaev68-dec-osf5.1a/bin/ar rc .libs/libgcj-tools.a  classpath/tools/libgcj_tools_la-tools.o
libtool: link: /usr/local/alphaev68-dec-osf5.1a/bin/ranlib .libs/libgcj-tools.a
libtool: link: ( cd ".libs" && rm -f "libgcj-tools.la" && ln -s "../libgcj-tools.la" "libgcj-tools.la" )
/usr/local/bin/bash ./libtool --tag=GCJ --mode=link /home/htl10/tmp-build/gcc-446-obj/gcc/gcj -B/home/htl10/tmp-build/gcc-446-obj/alphaev68-dec-osf5.1a/libjava/ -B/home/htl10/tmp-build/gcc-446-obj/gcc/ -L/home/htl10/tmp-build/gcc-446-obj/alphaev68-dec-osf5.1a/libjava -mieee -g -O2  -o jv-convert --main=gnu.gcj.convert.Convert -rpath /usr/local/lib -shared-libgcc    -L/home/htl10/tmp-build/gcc-446-obj/alphaev68-dec-osf5.1a/libjava/.libs libgcj.la 
libtool: link: /home/htl10/tmp-build/gcc-446-obj/gcc/gcj -B/home/htl10/tmp-build/gcc-446-obj/alphaev68-dec-osf5.1a/libjava/ -B/home/htl10/tmp-build/gcc-446-obj/gcc/ -mieee -g -O2 -o .libs/jv-convert --main=gnu.gcj.convert.Convert -shared-libgcc  -L/home/htl10/tmp-build/gcc-446-obj/alphaev68-dec-osf5.1a/libjava/.libs -L/home/htl10/tmp-build/gcc-446-obj/alphaev68-dec-osf5.1a/libjava ./.libs/libgcj.so -lpthread -lrt -Wl,-rpath -Wl,/usr/local/lib
/bin/ld:
Invalid flag usage: Wl,-rpath, -Wx,-option must appear after -_SYSTYPE_SVR4 
/bin/ld: Usage: /bin/ld [options] file [...]
collect2: ld returned 1 exit status
make[3]: *** [jv-convert] Error 1
make[3]: Leaving directory `/home/htl10/tmp-build/gcc-446-obj/alphaev68-dec-osf5.1a/libjava'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/home/htl10/tmp-build/gcc-446-obj/alphaev68-dec-osf5.1a/libjava'
make[1]: *** [all-target-libjava] Error 2
make[1]: Leaving directory `/home/htl10/tmp-build/gcc-446-obj'
make: *** [all] Error 2

-------------
Comment 10 Hin-Tak Leung 2011-04-30 20:46:02 UTC
Just upgrading from libtool 2.2 to 2.4 to see if that works. This looks relevant 
http://lists.gnu.org/archive/html/libtool-patches/2010-08/msg00305.html ?
since the next to current libtool 2.2.10 was on 09-Jun-2010, this probably means it has to be libtool 2.4 or a snapshot.
Comment 11 Hin-Tak Leung 2011-05-01 10:14:49 UTC
This really looks like a libtool/automake/autoconf problem, and it seems that libjava has its own libtool bundle?

Anyway, upgrading the system libtool to 2.4 does not improve.
Comment 12 Rainer Orth 2011-07-19 12:09:44 UTC
The system libtool is irrelevant since it isn't used, rather the in-tree one.
Could you please try this with a gcc 4.6.1 tarball?  I don't test GCC 4.4
any longer.

Thanks.
  Rainer
Comment 13 Rainer Orth 2011-07-19 12:11:27 UTC
One other possible problem: please avoid relative pathnames to configure and
an object directory that is a subdir of the source tree.  Better do (say)

mkdir /vol/gcc/obj/gcc-4.6.1
cd /vol/gcc/obj/gcc-4.6.1
/vol/gcc/src/gcc-4.6.1/configure <options>
Comment 14 Hin-Tak Leung 2011-08-02 23:31:30 UTC
(In reply to comment #13)
> One other possible problem: please avoid relative pathnames to configure and
> an object directory that is a subdir of the source tree.  Better do (say)
> 
> mkdir /vol/gcc/obj/gcc-4.6.1
> cd /vol/gcc/obj/gcc-4.6.1
> /vol/gcc/src/gcc-4.6.1/configure <options>

Tried specifying full path instead of relative path in configure. Still exactly the same problem. With 4.6.1 (source is untar'ed to /home/htl10/tmp-build/gcc-4.4.6):

cd /home/htl10/tmp-build/
mkdir gcc-446-obj
cd gcc-446-obj
/home/htl10/tmp-build/gcc-4.4.6/configure
make

last part of output:
-------------------
libtool: link: /home/htl10/tmp-build/gcc-446-obj/gcc/gcj -B/home/htl10/tmp-build/gcc-446-obj/alphaev68-dec-osf5.1a/libjava/ -B/home/htl10/tmp-build/gcc-446-obj/gcc/ -mieee -g -O2 -o .libs/jv-convert --main=gnu.gcj.convert.Convert -shared-libgcc  -L/home/htl10/tmp-build/gcc-446-obj/alphaev68-dec-osf5.1a/libjava/.libs -L/home/htl10/tmp-build/gcc-446-obj/alphaev68-dec-osf5.1a/libjava ./.libs/libgcj.so -lpthread -lrt -Wl,-rpath -Wl,/usr/local/lib
/bin/ld:
Invalid flag usage: Wl,-rpath, -Wx,-option must appear after -_SYSTYPE_SVR4 
/bin/ld: Usage: /bin/ld [options] file [...]
collect2: ld returned 1 exit status
make[3]: *** [jv-convert] Error 1
make[3]: Leaving directory `/home/htl10/tmp-build/gcc-446-obj/alphaev68-dec-osf5.1a/libjava'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/home/htl10/tmp-build/gcc-446-obj/alphaev68-dec-osf5.1a/libjava'
make[1]: *** [all-target-libjava] Error 2
make[1]: Leaving directory `/home/htl10/tmp-build/gcc-446-obj'
make: *** [all] Error 2
bash-2.05a# 
------------------------
Comment 15 ro@CeBiTec.Uni-Bielefeld.DE 2011-08-03 11:37:17 UTC
> last part of output:
> -------------------
> libtool: link: /home/htl10/tmp-build/gcc-446-obj/gcc/gcj
> -B/home/htl10/tmp-build/gcc-446-obj/alphaev68-dec-osf5.1a/libjava/
> -B/home/htl10/tmp-build/gcc-446-obj/gcc/ -mieee -g -O2 -o .libs/jv-convert
> --main=gnu.gcj.convert.Convert -shared-libgcc 
> -L/home/htl10/tmp-build/gcc-446-obj/alphaev68-dec-osf5.1a/libjava/.libs
> -L/home/htl10/tmp-build/gcc-446-obj/alphaev68-dec-osf5.1a/libjava
> ./.libs/libgcj.so -lpthread -lrt -Wl,-rpath -Wl,/usr/local/lib
> /bin/ld:
> Invalid flag usage: Wl,-rpath, -Wx,-option must appear after -_SYSTYPE_SVR4 

I've no idea what's going on there: modulo pathname and target triplet
differences, I have exactly the same gcj command line to link
jv-convert.  Could you please manually invoke that command with -v
added, so I can see how exactly collect2 resp. ld is called?

What I do see is that if you add some -W option to ld, you get exactly
the message you observe.  E.g.

ld -G 8 -O3 -S -call_shared -o .libs/jv-convert /usr/lib/cmplrs/cc/crt0.o -L.libs -L. -L../../gcc -L/usr/lib/cmplrs/cc gnu.gcj.convert.Convertmain.o ./.libs/libgcj.so -lpthread -lrt -rpath /vol/gcc/lib -lgcc_s -lgcc -lgcj -lm -liconv -lpthread -lrt -lgcc_s -lgcc -lc -lgcc_s -lgcc -Wno-unused
ld:
Invalid flag usage: Wno-unused, -Wx,-option must appear after -_SYSTYPE_SVR4 
ld: Usage: ld [options] file [...]

Do you happen to have some environment variable set to -W<something>?
Though I have found no hint that ld would check for this, it's a
possibility.

	Rainer
Comment 16 Hin-Tak Leung 2011-08-03 15:38:30 UTC
(In reply to comment #15)

> > Invalid flag usage: Wl,-rpath, -Wx,-option must appear after -_SYSTYPE_SVR4 
> 

> What I do see is that if you add some -W option to ld, you get exactly
> the message you observe.  E.g.

That's stating the obvious... it is essentially what the error message is complaining ('flags must be ordered in some way")

> Do you happen to have some environment variable set to -W<something>?
> Though I have found no hint that ld would check for this, it's a
> possibility.

No I don't - just tried export |grep W . In any case, 4.6.1 does not show this problem, so it seems to be fixed in 4.6.1 somehow; and it is *not* full/relative path related.
Comment 17 ro@CeBiTec.Uni-Bielefeld.DE 2011-08-03 15:42:46 UTC
>> > Invalid flag usage: Wl,-rpath, -Wx,-option must appear after -_SYSTYPE_SVR4 
>
>> What I do see is that if you add some -W option to ld, you get exactly
>> the message you observe.  E.g.
>
> That's stating the obvious... it is essentially what the error message is
> complaining ('flags must be ordered in some way")

Not really: there's no documented -_SYSTYPE_SVR4 flag, and ld doesn't
accept such a flag at all.  The error message is sort of nonsensical.

>> Do you happen to have some environment variable set to -W<something>?
>> Though I have found no hint that ld would check for this, it's a
>> possibility.
>
> No I don't - just tried export |grep W . In any case, 4.6.1 does not show this
> problem, so it seems to be fixed in 4.6.1 somehow; and it is *not*
> full/relative path related.

Still really strange: I've never seen such a ld message before, building
gcc or otherwise.

Anyway, great that it works for you now.

	Rainer
Comment 18 Hin-Tak Leung 2011-08-05 05:47:12 UTC
4.4.6 fails, 4.5.x fails earlier in a different Bug 44959 ; 4.6.1 works so closing.
Comment 19 Hin-Tak Leung 2012-09-01 14:31:40 UTC
(In reply to comment #18)
> 4.4.6 fails, 4.5.x fails earlier in a different Bug 44959 ; 4.6.1 works so
> closing.

After editing config/bootstrap-debug.mk as in (
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44959#c32), 4.5.0 fails with this.

Am going to try every version of gcc in 4.5.x and 4.6.x and see when was it fixed...
Comment 20 Hin-Tak Leung 2012-09-10 16:27:57 UTC
re-test everything, somehow 4.3.3 fails - it would appear that I upgraded libtool and thing got broken; in any case, 4.6.x and 4.7.x works, and 4.5.x fails; and 4.4.7 fails. Hmm, I should re-try 4.4.1 to be sure.
Comment 21 Hin-Tak Leung 2012-09-10 21:20:17 UTC
re-test and 4.4.1 fails.