Re: bootstrap/3472: 3.0 fails on sparc-sun-solaris2.7 (problems with either GNU ld or Sun ld)

Re: bootstrap/3472: 3.0 fails on sparc-sun-solaris2.7 (problems with either GNU ld or Sun ld)

[Dimitri Papadopoulos]

The following reply was made to PR bootstrap/3472; it has been noted by GNATS.

From: Dimitri Papadopoulos <papadopo.BIDON@BIDON.shfj.cea.fr.cea.fr>
To: gcc-gnats@gcc.gnu.org, gcc-prs@gcc.gnu.org, gcc-bugs@gcc.gnu.org,
        nobody@gcc.gnu.org
Cc:  
Subject: Re: bootstrap/3472: 3.0 fails on sparc-sun-solaris2.7 (problems with 
 either GNU ld or Sun ld)
Date: Mon, 02 Jul 2001 10:12:17 +0200

 > State-Changed-From-To: open->closed
 
 I don't agree. See below.
 
 
 > State-Changed-By: aoliva
 > State-Changed-When: Fri Jun 29 20:09:30 2001
 > State-Changed-Why:
 >     See http://gcc.gnu.org/install/specific.html#sparc-sun-solaris
 
 The above link does not exist, but I guess you mean
 	http://gcc.gnu.org/install/specific.html#sparc-sun-solaris*
 
 Actually the above link is dead as well, but this is because the whole
 page is messed up. It has been lacking <a name="..."> for weeks.
 
 
 Actually I can't find anything in the platform notes about this
 error I get with Sun ld:
 	collect2: ld returned 1 exit status
 
 
 What I find is this about GNU ld:
 	All releases of GNU binutils prior to 2.11.1 have known bugs
 	on this platform. We recommend the use of GNU binutils 2.11.1
 	or the vendor tools (Sun as, Sun ld).
 And indeed GCC does build with GNU binutils 2.11.2.
 
 
 But it still doesn't build with Sun ld. All I could find about Sun ld:
 	Unfortunately, C++ shared libraries, including libstdc++, won't
 	work properly if assembled with Sun as: the linker will complain
 	about relocations in read-only sections, in the definition of
 	virtual tables. Also, Sun as fails to process long symbols
 	resulting from mangling template-heavy C++ function names.
 I have already seen such errors in the past and I am well aware of
 this limitation. But it doesn't seem to apply here, does it?
 
 
 By the way the last sentence of the above paragraph does not apply
 to recent versions of Sun ld:
 	Also, Sun as fails to process long symbols resulting from
 	mangling template-heavy C++ function names.
 
 As pointed out by another paragraph in the same page:
 	Sun as 4.X is broken in that it cannot cope with long symbol
 	names. A typical error message might look similar to the
 	following:
 		/usr/ccs/bin/as: "/var/tmp/ccMsw135.s", line 11041: error: can't compute value of an expression involving an external symbol. 
 	This is Sun bug 4237974. This is fixed with patch 108908-02
 	and has been fixed in later (5.x) versions of the assembler.
 
 
 Which paragraph covers the Sun ld issue?
 
 
 Dimitri Papadopoulos

Re: bootstrap/3472: 3.0 fails on sparc-sun-solaris2.7 (problems with either GNU ld or Sun ld)

[aoliva]

Synopsis: 3.0 fails on sparc-sun-solaris2.7 (problems with either GNU ld or Sun ld)

State-Changed-From-To: open->closed
State-Changed-By: aoliva
State-Changed-When: Fri Jun 29 20:09:30 2001
State-Changed-Why:
    See http://gcc.gnu.org/install/specific.html#sparc-sun-solaris

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=3472&database=gcc

bootstrap/3472: 3.0 fails on sparc-sun-solaris2.7 (problems with either GNU ld or Sun ld)

[papadopo]

>Number:         3472
>Category:       bootstrap
>Synopsis:       3.0 fails on sparc-sun-solaris2.7 (problems with either GNU ld or Sun ld)
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Fri Jun 29 01:26:00 PDT 2001
>Closed-Date:
>Last-Modified:
>Originator:     Dimitri Papadopoulos
>Release:        3.0
>Organization:
>Environment:
Solaris 2.7 on SPARC, gcc version 2.95.3, GNU ld version 2.10.1
Solaris 2.7 on SPARC, gcc version 2.95.3, Sun ld version 4.0
>Description:
I've tried to 'make bootstrap' GCC 3.0 with both Sun ld and GNU ld.

With GNU ld I get the usual 'libgcc.map: file format not recognized' error already reported here:
	http://gcc.gnu.org/ml/gcc-bugs/2001-06/msg01030.html
Unfortunately there was no reply to this bug report. Is there any known workaround?

Then I tried with Sun ld. I get an error when linking libgcj.so.2.0.0:
/tmp/gcc-3.0/gcc/xgcc -B/tmp/gcc-3.0/gcc/ -B/usr/local/gcc-3.0/sparc-sun-solaris2.7/bin/ -B/usr/local/gcc-3.0/sparc-sun-solaris2.7/lib/ -isystem /usr/local/gcc-3.0/sparc-sun-solaris2.7/include -shared -Wl,-h -Wl,libgcj.so.2 -o .libs/libgcj.so.2.0.0 [...] -z allextract ../libffi/.libs/libfficonvenience.a ./libltdl/.libs/libltdlc.a -z defaultextract  -L/tmp/gcc-3.0/sparc-sun-solaris2.7/libjava ../libffi/.libs/libfficonvenience.a -lpthread -lrt ./libltdl/.libs/libltdlc.a -ldl   -lc
collect2: ld returned 1 exit status
gmake[3]: *** [libgcj.la] Error 1
gmake[3]: Leaving directory `/tmp/gcc-3.0/sparc-sun-solaris2.7/libjava'
gmake[2]: *** [all-recursive] Error 1
gmake[2]: Leaving directory `/tmp/gcc-3.0/sparc-sun-solaris2.7/libjava'
gmake[1]: *** [all-target-libjava] Error 2
gmake[1]: Leaving directory `/tmp/gcc-3.0'
gmake: *** [bootstrap] Error 2

Maybe the very long list of object files linked into libgcj.so results in too long a command line for Solaris?
Any workaround? I don't need the java compiler right now.
>How-To-Repeat:

>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted: