Re: middle-end/7617: shared libgcc binary incompatibility on sparc-sun-solaris2.8

Re: middle-end/7617: shared libgcc binary incompatibility on sparc-sun-solaris2.8

[ehrhardt]

Synopsis: shared libgcc binary incompatibility on sparc-sun-solaris2.8

State-Changed-From-To: analyzed->closed
State-Changed-By: cae
State-Changed-When: Wed Dec 11 09:39:22 2002
State-Changed-Why:
    As mentioned in the audit trail binutils prior to 2.13.1 generates
    broken shared libraries. The underlying cause is an incompatibility
    between GNU binutils and Solaris ld.so.1 with R_SPARC_RELATIVE
    relocation records. Depending on the linker flags used for ld (-z nocomreloc)
    SUN ld.so.1 may or may not link these libraries correctly.
    The fix is to upgrade to binutils-2.13.1 and recompile gcc.

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=7617

Re: middle-end/7617: shared libgcc binary incompatibility on sparc-sun-solaris2.8

[Daniel Jacobowitz]

The following reply was made to PR middle-end/7617; it has been noted by GNATS.

From: Daniel Jacobowitz <drow@mvista.com>
To: morey@astech.org
Cc: nbryant@allegientsystems.com, gcc-gnats@gcc.gnu.org,
	gcc-prs@gcc.gnu.org, gcc-bugs@gcc.gnu.org, nobody@gcc.gnu.org
Subject: Re: middle-end/7617: shared libgcc binary incompatibility on sparc-sun-solaris2.8
Date: Sat, 12 Oct 2002 00:02:57 -0400

 On Fri, Oct 11, 2002 at 08:10:43PM +0700, morey@astech.org wrote:
 > I have been experiencing the same problems.  I have been using binutils-2.13.  After extensive playing around I have noticed
 > 
 > a few things.  If you compile a simple program that is dynamically linked with libgcc_s.so it will crash in __init with a
 > 
 > SIGSEV.  However, if it is compiled with -static the program will run fine.  I then rebuilt gcc and had it use the solaris ld
 > 
 > and as and how a program the dynamically linked with libgcc_s.so will run fine.  It appears to be a problem related to binutils-2.13.
 > 
 > I will try an older version and see if I can track down what exactly is causing the problem.
 > 
 > http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=7617
 
 Get a binutils CVS head snapshot.  This is recently fixed and we'll be
 releasing a fixed 2.13.1 in a couple of weeks hopefully.
 
 -- 
 Daniel Jacobowitz
 MontaVista Software                         Debian GNU/Linux Developer

Re: middle-end/7617: shared libgcc binary incompatibility on sparc-sun-solaris2.8

[morey]

The following reply was made to PR middle-end/7617; it has been noted by GNATS.

From: morey@astech.org
To: nbryant@allegientsystems.com, gcc-gnats@gcc.gnu.org,
	gcc-prs@gcc.gnu.org, gcc-bugs@gcc.gnu.org, nobody@gcc.gnu.org
Cc:  
Subject: Re: middle-end/7617: shared libgcc binary incompatibility on 
 sparc-sun-solaris2.8
Date: Fri, 11 Oct 2002 20:10:43 +0700

 I have been experiencing the same problems.  I have been using binutils-2.13.  After extensive playing around I have noticed
 
 a few things.  If you compile a simple program that is dynamically linked with libgcc_s.so it will crash in __init with a
 
 SIGSEV.  However, if it is compiled with -static the program will run fine.  I then rebuilt gcc and had it use the solaris ld
 
 and as and how a program the dynamically linked with libgcc_s.so will run fine.  It appears to be a problem related to binutils-2.13.
 
 I will try an older version and see if I can track down what exactly is causing the problem.
 
 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=7617
 
 
 

Re: middle-end/7617: shared libgcc binary incompatibility on sparc-sun-solaris2.8

[davem]

Synopsis: shared libgcc binary incompatibility on sparc-sun-solaris2.8

State-Changed-From-To: open->analyzed
State-Changed-By: davem
State-Changed-When: Thu Sep 26 03:40:17 2002
State-Changed-Why:
    There have been a lot of problems reported by Solaris users
    using binutils-2.13, using binutils-2.12 might help.
    This is just a guess since I do not use the Solaris platform.

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=7617

Re: middle-end/7617: shared libgcc binary incompatibility on sparc-sun-solaris2.8

[Nathan Bryant]

The following reply was made to PR middle-end/7617; it has been noted by GNATS.

From: Nathan Bryant <nbryant@allegientsystems.com>
To: nbryant@allegientsystems.com, gcc-gnats@gcc.gnu.org, gcc-prs@gcc.gnu.org,
   gcc-bugs@gcc.gnu.org
Cc:  
Subject: Re: middle-end/7617: shared libgcc binary incompatibility on sparc-sun-solaris2.8
Date: Fri, 16 Aug 2002 19:16:44 -0400

 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=7617
 
 I have some more info on this PR; it's not just a binary incompatibility 
 with libgcc_s.so; shared libgcc seems to be broken entirely, since I am 
 unable to build very simple C shared libraries that don't segfault, with 
 gcc 3.2+binutils 2.13 with gcc 3.2 configured as described in the PR.
 
 Sorry for the misleading PR. It seems that the only thing needed to 
 reproduce the problem is gcc3.2 itself (and perhaps this specific binutils.)
 
 At the moment, unfortunately, I am unable to get anything useful out of 
 gdb since gdb is one of my binaries that got broken; the gdb binary i've 
 moved from another system has problems and seems unable to connect to 
 the child process.
 

middle-end/7617: shared libgcc binary incompatibility on sparc-sun-solaris2.8

[nbryant]

>Number:         7617
>Category:       middle-end
>Synopsis:       shared libgcc binary incompatibility on sparc-sun-solaris2.8
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Fri Aug 16 14:56:00 PDT 2002
>Closed-Date:
>Last-Modified:
>Originator:     nbryant@allegientsystems.com
>Release:        gcc-3.2
>Organization:
>Environment:
sparc solaris-2.8
>Description:
Recently I upgraded a sparc-sun-solaris2.8 box to gcc 3.2 and binutils 2.13 and now my binaries compiled with gcc 3.0.4 seem to have stopped working.

as best as i can remember, my upgrade path went something like this:

* original installation of GNU toolchain with gcc 3.0.4 from sunfreeware
* installed binutils, probably 2.11.something
* at this point i think i recompiled gcc 3.0.4 with itself to get a working java version using binutils. most of my binaries and libraries in /usr/local were then compiled with this toolchain.

* upgraded to binutils 2.12.1 and gcc 3.1, both built from source. I didn't build too many binaries with this toolchain, but I believe all my old binaries still worked at this point.

* built and installed binutils 2.13 from source. no special configure options.
* built and installed gcc-3.2 from source, configured as follows:

nbryant@sundev:~/src$ gcc -v
Reading specs from /usr/local/lib/gcc-lib/sparc-sun-solaris2.8/3.2/specs
Configured with: /export/home/nbryant/src/gcc-3.2/configure --with-gnu-as --with-gnu-ld --enable-threads --with-as=/usr/local/bin/as --with-ld=/usr/local/bin/ld --enable-libgcj --with-system-zlib --with-cpu=ultrasparc
Thread model: posix
gcc version 3.2

At this point, I noticed that any of my old binaries linked with libgcc_s no longer work; they dump core immediately on startup. This means that anything linked with a C shared library built with the older gcc can't work.

I believe my gcc 3.0.4 was configured identically, but without --with-cpu=ultrasparc and without --with-system-zlib, probably. in all cases, binutils was built without options.

Can somebody please tell me what version of these tools I should be using to ensure C ABI compatibility going forward? 
>How-To-Repeat:

>Fix:

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