This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: Versioning mess proved!!!
- To: Philip Blundell <philb at gnu dot org>
- Subject: Re: Versioning mess proved!!!
- From: Franz Sirl <Franz dot Sirl-kernel at lauterbach dot com>
- Date: Sun, 1 Oct 2000 23:08:28 +0200
- Cc: Ulrich Drepper <drepper at redhat dot com>,Jack Howarth <howarth at fuse dot net>,libc-alpha at sourceware dot cygnus dot com,aj at suse dot de
- References: <39D50E20.263F646F@fuse.net> <00100118123900.01271@enzo.bigblue.local> <E13foIZ-0001J6-00@kings-cross.london.uk.eu.org>
On Sun, 01 Oct 2000, Philip Blundell wrote:
> >Uli, actually I think your patch broke this, WEAK_GMON_START was never
> >defined for PPC, we always had the dummy weak __gmon_start__() routine
> > which Philips patch removed. Can we really change this without breaking
> > binary compatibility?
>
> I thought Geoff said at the time that PPC worked OK without the dummy weak
> definition. What's the actual issue that breaks it?
Backwards compatibility? Actually I can't do much better in this area, cause
the innards of the shared library loading are still mostly a mystery to me.
Maybe it's not possible to have backwards compatibility, maybe the shared lib
loader has a bug, maybe...? I think Geoff is the one to ask here, or maybe
somebody can give me some hints on what to look next.
What I know is that libc-2.1.94 + zlib.so-compiled-against-2.1.94 +
zlib-example-compiled-against-2.1.3 segfaults on PPC.
The segfault happens in call_gmon_start, cause *gmon_start is not zero. It
seems like *gmon_start got relocated to a "ba 0", that's an absolute branch
to 0 on PPC, which naturally segfaults.
Well, maybe I should ask the other way round, are there any advantages of the
current code to the previous one? Does PPC have to change at all?
Franz.