This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
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 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.