[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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: