Re: libX11 is borked (or is it glibc ?)
Ben Collins <bcollins@debian.org> writes:
> On Mon, Oct 16, 2000 at 01:10:03AM -0400, James Antill wrote:
> > Daniel Jacobowitz <dan@debian.org> writes:
> >
> > > On Mon, Oct 16, 2000 at 01:59:11AM +0200, Johannes Zellner wrote:
> > > > Hello,
> > > >
> > > > I cannot link any more against libX11.so:
> > > >
> > > > /usr/X11R6/lib/libX11.so: undefined reference to `getpwnam_r@@GLIBC_2.0'
> > > >
> > > > this shows, even if I link a minimal c program.
> > > >
> > > > my versions:
> > > > ii xlib6g 3.3.6-11
> > > > ii libc6 2.1.94-3
> > > >
> > > > Any comments ?
> > >
> > > To compile against a library built under an old glibc, the library
> > > needs to be recompiled to the new libc.
> >
> > If this is true then there isn't any binary compatibility.
> > The whole point of the symbols looking like the above is so that
> > there can be multiple versions of them. Eg.
>
> Binary compatibility means you con run programs linked against older
> libraries. Guess what, X and the libX11 linked apps still work don't they?
To me "binary compatible" means that, things act as they did before
... when linked with the old library. Which includes being able to
"run" your old libraries linked against old libraries.
> > % nm -g /usr/lib/debug/libc-2.1.3.so | egrep GLIB | egrep chown
> > 000913c8 T __chown@@GLIBC_2.1
> > 000913c8 T chown@@GLIBC_2.1
> > 00091454 T chown@GLIBC_2.0
> > % nm -g /usr/lib/debug/libc-2.1.3.so | egrep GLIB | egrep fopen
> > 0004b5c4 T _IO_file_fopen@@GLIBC_2.1
> > 0004da48 T _IO_file_fopen@GLIBC_2.0
> > 000481e0 T _IO_fopen@@GLIBC_2.1
> > 0004a9a0 T _IO_fopen@GLIBC_2.0
> > 000481e0 T fopen@@GLIBC_2.1
> > 0004a9a0 T fopen@GLIBC_2.0
> >
> > So either something bad has happened with the glibc versioning
> > upstream or glibc was built badly.
>
> No, this is inherent in versioned symbols. The old symbol is now "weak",
> which means it is there for using by old programs, but cannot be used when
> linking. A weak symbol keeps compatibility, which allowing the new strong
> symbol to be used for newly compiled applications.
This seems wrong, for instance ulimit() is a weak alias for
__ulimit. But maybe you mean something different ?
I was pretty sure that I'd compiled/linked programs against glibc-2.1.3
and another library that used 2.0.7. Maybe I'm getting senile in my
old age or maybe it worked but doesn't guarantee it.
Ahh well learn something bad every day I guess.
--
James Antill -- james@and.org
"If we can't keep this sort of thing out of the kernel, we might as well
pack it up and go run Solaris." -- Larry McVoy.
Reply to: