title: Resolving library dependencies of older software link: https://onemoretech.wordpress.com/2009/01/03/resolving-library-dependencies-of-older-software/ author: lembobro description: post_id: 409 created: 2009/01/03 17:18:08 created_gmt: 2009/01/03 17:18:08 comment_status: open post_name: resolving-library-dependencies-of-older-software status: publish post_type: post

Resolving library dependencies of older software

Someone could write a whole book on this topic, let alone all the other aspects of installing old software on new systems. Even when the O/S involved is relatively nimble when it comes to adjusting to old hardware, the world of userland applications can be treacherous. Thankfully, Linux is much better nowadays than Windows at interfacing with older hardware. Most open source software has or can be either re-packaged, recompiled or reconfigured to work as well. The problem is almost always with closed-source software, whether drivers or application programs.

I recently moved most of my Linux boxes over to Ubuntu, after several years on Red Hat Enterprise/CentOS. There’s a lot of closed-source software available for Red Hat because it’s the de facto standard for enterprise Linux — no matter what Novell or Oracle would like gullible executive types to believe (Oracle’s release of their Unbreakable Linux, which is little more than a repackaging of CentOS, is confirmation of this fact). Making most of that stuff work on other distros can be a daunting task, because often they require libraries that have either been entirely deprecated or superseded.

There’s a process to handling this kind of issue. Mostly it starts with running what’s failing from the command line to see if any useful debugging information gets displayed in standard output. Sometimes you have to check the system logs, or run the binary through a special debugger. In a recent case I was lucky enough to get results from the former.

In trying to run the setup program for Sun Java Systems Directory Server 5.2, it barked back a message that it couldn’t find libstdc++-libc6.2.2.so.3, and died.

One method of finding what package provides a particular library is run the command:

apt-file update; apt-file search [filename].

(apt-file is not installed by default, do an “apt-get install apt-file”)

In my case I substituted libstdc++-libc6.2.2.so.3 for [filename]. Unfortunately, the system promptly returned… nothing.

After googling around a bit, I found out that this library hasn’t been included in Ubuntu since Gutsy (that’s “Gutsy Gibbon” or version 7.10, which was released in October 2007 and ended life in October 2008), but in that release had been provided by the libstdc++2.10-glibc2.2 package.

There is a wishlist bug seeking to have this library restored to Hardy (8.04), Intrepid (8.10) and future versions, but since the whole glibc infrastructure it was part of has been superceded, no one should hold their breath.

The bug report and various posts, did confirm the library file was contained in a package called libstdc++2.10-glibc2.2 in the Gutsy repository. This could be got from either this or this location.

After downloading the package, I extracted it’s contents to a temporary directory called /tmp/libstdctmp using

dpkg -x libstdc++2.10-glibc2.2.deb /tmp/libstdctmp

and then copied the files under libstdctmp/usr/lib into /usr/lib32 (/usr/lib being for 64-bit binaries on x86_64 Ubuntu, the reverse of the practice on Red Hat systems — where /usr/lib64 is reserved for 64-bit libs and /usr/lib continues to the hold 32-bit ones). I then ran Sun’s setup program again and voila, it worked!

Copyright 2004-2019 Phil Lembo