From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3250 invoked by alias); 5 Aug 2002 19:59:56 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 3241 invoked from network); 5 Aug 2002 19:59:55 -0000 Received: from unknown (HELO linuxpc1.lauterbach.com) (213.70.137.66) by sources.redhat.com with SMTP; 5 Aug 2002 19:59:55 -0000 Received: (qmail 17292 invoked by uid 82); 5 Aug 2002 19:59:53 -0000 Received: from Franz.Sirl-kernel@lauterbach.com by linuxpc1.lauterbach.com with qmail-scanner-1.01 (inocmd32: /. . Clean. Processed in 0.869779 secs); 05 Aug 2002 19:59:53 -0000 Received: from dsl-213-023-062-199.arcor-ip.net (HELO enzo) (213.23.62.199) by linuxpc1.lauterbach.com with SMTP; 5 Aug 2002 19:59:52 -0000 Content-Type: text/plain; charset="iso-8859-1" From: Franz Sirl To: Jakub Jelinek Subject: Re: [PATCH] 3.2: Fixup symbol versioning mistake on powerpc-linux-gnu Date: Mon, 05 Aug 2002 12:59:00 -0000 User-Agent: KMail/1.4.2 Cc: gcc-patches@gcc.gnu.org, Richard Henderson , Mark Mitchell , "H. J. Lu" References: <200208042102.02876@enzo.bigblue.local> <200208052042.35284@enzo.bigblue.local> <20020805150825.B1596@devserv.devel.redhat.com> In-Reply-To: <20020805150825.B1596@devserv.devel.redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200208052159.42836@enzo.bigblue.local> X-SW-Source: 2002-08/txt/msg00312.txt.bz2 On Montag, 5. August 2002 21:08, Jakub Jelinek wrote: > On Mon, Aug 05, 2002 at 08:42:35PM +0200, Franz Sirl wrote: > > You would be right in an ideal world, but I've already seen this in the > > wild, mostly with with really complex apps like OpenOffice depending on > > other complex apps like mozilla. The problem is that glibc also exports > > these 4 symbols with link-time reference (fixing that will be a follow-up > > patch) and > > IMHO its just PPC which should not export it, IA-32 and others > always exported this and it is not causing problems there. IMO it should have been never exported as a versioned link-time reference from glibc on any platform, it simply isn't necessary. > > there are still a bunch of apps that manually link shared libs with -lc > > -lgcc (like openssl, KDE, mozilla, etcetc) instead of -lgcc -lc -lgcc or > > using gcc to link. > > Apps using ld -shared instead of gcc -shared and g++ -shared need to > be fixed, not workarounds added so that they can stay being broken some > more time. Hehe, have a lot of fun fixing libtool then :-). > > That caused an undefined reference for __divdi3@GLIBC_2.0 when > > running on a gcc2 compiled glibc, even though libgcc_s.so was delivered > > with the app. > > Now you could argue "this only happens during the transition", but > > history shows us that things like that will bite us again and again :-). > > I still think it is enough just to change glibc. I don't have enough support power to rely on "I think" :-). Unlike you come up with a really convincing argument for not doing it, I would like to fix that. IMHO the initial bug was that gcc/config/libgcc-glibc.ver isn't generic as it's placement would suggest, but x86 specific and should have been placed in gcc/config/i386/. gcc/config/libgcc-glibc.ver shouldn't have included the divmod symbols. But the deed is done and if gcc-3.0 and gcc-3.1 binaries wouldn't be that widely deployed on PPC I would even go as far as creating a gcc/config/rs6000/libgcc-glibc.ver without the divmod symbols, but I'm reluctant to do that as long as there is no glibc release (2.2.6/2.3) with the ppc versioning changes that would fulfill the symbol versions then missing from libgcc_s. Hmm, but I would rather have that change than no change at all, even if that would require people to upgrade to an unreleased glibc. Hmm, maybe the full compat patch for 3.2 and only a fixed gcc/config/rs6000/libgcc-glibc.ver for 3.3? Such a transition period would be acceptable to me. Franz.