This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] 3.2: Fixup symbol versioning mistake on powerpc-linux-gnu

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 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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]