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 <[EMAIL PROTECTED]> 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
