Re: glibc 2.2.5 incompatibility for (old) existing binaries.
Sorry for the belated reply.
On Sun, Feb 09, 2003 at 08:02:56AM -0800, Karl J. Runge wrote:
> 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...)
Yes, that looks like what they're doing.
> 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
It's not documented. You'll have to get the glibc SRPM from them to
see how they do it; search for VERNEED in glibc-redhat.patch.
> > 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.)
It wasn't intentional/malicious, but I think it may have been
intentional/necessary. It's related to the changes for transitioning
to thread-local storage, I bet.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
Reply to: