This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: Versioning mess proved!!!
On Sun, Oct 01, 2000 at 09:48:11PM -0700, Geoff Keating wrote:
> > Reply-To: drepper@cygnus.com (Ulrich Drepper)
> > From: Ulrich Drepper <drepper@redhat.com>
> > Date: 01 Oct 2000 16:57:45 -0700
>
> > > It just means that the PLT entry will jump to location 0, but that
> > > should never happen because the entry in the GOT will be zero since
> > > the symbol is never defined.
> >
> > Right. And ld.so handles this correctly in general. So why are you
> > seeing the crashes? I still have not seen any explanation.
>
> Just to be clear, I don't have a working glibc 2.1.9* system at
> present, due to tool & hardware & OS problems. I plan to spend some
> time on getting one going this week, but I'm very limited on the
> amount of time I can spend on glibc without getting behind on other
> things...
>
> Anyway, from the previous discussion it seems that the problem is that
> the executable has a PLT entry for __gmon_start__, which is
> reasonable, but that the GOT entry in libz.so is referring to this PLT
> entry even when __gmon_start__ is not defined anywhere, which is wrong
> (it would be OK if __gmon_start__ was defined, but it's undefined).
>
If it is wrong, I assume it is a bug in ld. Why shouldn't we fix ld?
I know there are a few unresolved ld problems on ppc and alpha. But
I don't have easy access to PPC. Telnet over a slow link into a slow
machine is not something I'd like to do :-). Also my alpha machine is
too slow to debug any big libraries like QT.
BTW, if you think it is a gcc bug which "miscompiles" initfini.c, you
can write a ppc specific version of initfini.c in asm. See
sysdeps/ia64/elf/initfini.c, sysdeps/sh/elf/initfini.c and
sysdeps/s390/initfini.c.
H.J.