From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28302 invoked by alias); 12 Mar 2002 00:06:03 -0000 Mailing-List: contact gcc-prs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-prs-owner@gcc.gnu.org Received: (qmail 28228 invoked by uid 71); 12 Mar 2002 00:06:02 -0000 Date: Mon, 11 Mar 2002 16:06:00 -0000 Message-ID: <20020312000602.28223.qmail@sources.redhat.com> To: nobody@gcc.gnu.org Cc: gcc-prs@gcc.gnu.org, From: "John David Anglin" Subject: Re: libstdc++/4260: ABI change beween 3.0 and 3.0.1 Reply-To: "John David Anglin" X-SW-Source: 2002-03/txt/msg00369.txt.bz2 List-Id: The following reply was made to PR libstdc++/4260; it has been noted by GNATS. From: "John David Anglin" To: phil@jaj.com (Phil Edwards) Cc: gcc-gnats@gcc.gnu.org, dave.anglin@nrc.ca, gcc-bugs@gcc.gnu.org Subject: Re: libstdc++/4260: ABI change beween 3.0 and 3.0.1 Date: Mon, 11 Mar 2002 18:59:08 -0500 (EST) > On Mon, Mar 11, 2002 at 05:02:57PM -0500, John David Anglin wrote: > > > You wrote in the audit trail for this PR that this is now okay. Can we > > > close the PR? > > > > Was any code changed to keep the library internal name and global > > constructors for the library consistent? > > libstdc++ doesn't have any control over the global constructors. Somebody in > compiler-land will have to make changes to collect2 to do this. Looking at the libtool command to build the library in my latest build, I see "-version-info 4:0:0". The generated internal name for the library is "-Wl,+h -Wl,libstdc++.sl.4". However, the global constructors are: _GLOBAL__FI_libstdc___sl_4_0 I don't fully understand how the global constructor names are generated but it is clear that there is a mismatch between the library internal name and the global constructor symbols. In the original report, a change in version from 3.0 to 3.0.1 caused a change in constructor symbol from _GLOBAL__FI_libstdc___sl_3_0 to _GLOBAL__FI_libstdc___sl_3_1 If the libraries were intended to be compatible, the constructor symbol shouldn't have changed. If not, the library internal name should have changed to match. Libtool probably needs to add another digit to the internal names that it generates for the PA som linker so that its precision matches that generated by collect2. However, it also looks like collect2 isn't generating global constructor names correctly. Thus, I don't believe the problem is resolved and we will have the same problem again when there is a minor version change. Dave -- J. David Anglin dave.anglin@nrc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6605)