Re: libX11 is borked (or is it glibc ?)
> > 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.
Your definition is incorrect.
> > > % 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 ?
And applications/libs using ulimit() reference __ulimit instead. But if a
lib referenced the ulimit weak symbol instead (somehow), then it would
have to be recompiled if you wanted to link against it (but it would still
continue to work as before).
> 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.
Not everything has to be recompiled. Just libs that use obsolete symbols
(ones that have changed to weak symbols for compatibility, but now have
newer versions of that symbol). We had this same issue with the 2.0.7 ->
2.1.0 upgrade. It was actually a lot more extensive than this upgrade.
> Ahh well learn something bad every day I guess.
Heh, I'd rather have this than have to recompile all applications because
versioned symbols did not exist to begin with. Atleast with this scheme,
we have an upgrade path (that wasn't there for the libc5 -> libc6
changeover).
Ben
--
-----------=======-=-======-=========-----------=====------------=-=------
/ Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \
` bcollins@debian.org -- bcollins@openldap.org -- bcollins@linux.com '
`---=========------=======-------------=-=-----=-===-======-------=--=---'
Reply to: