Re: glibc 2.2.5 incompatibility for (old) existing binaries.
On Sat, 8 Feb 2003, Daniel Jacobowitz <dan@debian.org> wrote:
> On Sat, Feb 08, 2003 at 11:19:44AM -0500, Karl J. Runge wrote:
> >
> > In doing some experimental upgrades to Debian 3.0 on test machines
> > on our LAN, I noticed an incompatibility: applications built on glibc
> > 2.0.7 (i.e. 1999 timeframe) now often fail unexpectedly on Debian 3.0
> > (glibc 2.2.5).
>
> FYI,
>
> I believe this is a known problem, and I believe that Red Hat solves it
> by a patch which runs 2.0.x binaries using a separate copy of the
> library, which is gross.
Yes it is, but not unfamiliar recalling the things done with linking
during the libc5 -> libc6 transition...
In fact, in this patch did they implement it similarly to the
lib5->lib6 workaround, i.e. by patching the dynamic linker to figure
out the right libraries to use?
It seems that could be done in this case by looking for an absence of
any GLIBC_2.x version dep. info in the application binary, then you
know it was compiled in the glibc 2.0.x timeframe with high probability
(still a gross hack, but I think it would mostly work...)
I can't find mention of what you refer to on RedHat's web site. Do you have
a pointer or keywords to help me find it? All I find is the older workaround
(Redhat 6.x timeframe) using LD_LIBRARY_PATH and a /usr/i386-glibc20-linux/lib/
set of shared objects:
http://www.redhat.com/support/wpapers/redhat/glibccompat/running.html
> They didn't really get the compatibility solutions working until 2.1.
Do you know if the problem I encountered (incompatibilities first seen
in glibc 2.2.5 evidently due to the handling of the stderr data
object), was intentional or accidental? My wad of 100's of glibc 2.0.7
compiled binaries works fine up to 2.2.4. So without additional info
I'd say it was an unintentional incompatibility and probably could have
been worked around if the glibc developers knew about it and really
wanted to.
I'm perhaps overly pessimistic, but I believe some year applications
built in the glibc 2.1.x timeframe will fall of the edge of the world
like my older apps did. I don't think all incompatibility problems can
be _easily_ worked around with the interface versioning scheme
introduced in glibc 2.1 (e.g. in my case the use of the stderr data
object might be spread over so many interfaces it would be undesirable
to use that scheme.)
Thanks,
Karl
Reply to: