Overriding Linux libraries for historical binary-only tools

Question

I have a 64 bit Ubuntu Linux box. Recently I was given an old compiled binary that used to run on an old, retired server, which I THINK was a 2007-era Redhat distribution.

As you might expect, the binary does not work because of library incompatabilities. Binary-only sucks and isn't MEANT to be portable. Yet I'm still stuck with just the binary, and a need to run it. So my question becomes how to deal with the (painful) problem of figuring just what libraries the binary is expecting, finding those libraries, and forcing the program to use them. What's the proper strategy for doing this?

I'll give you the specific example of my binary, which runs but immediately fails with the error message

datab2txt: relocation error: /lib64/libnss_files.so.2: symbol __rawmemchr, version GLIBC_2.2.5 not defined in file libc.so.6 with link time reference

I'm interested in the strategy to diagnose this since I expect that if I solve this problem (by finding an old version of glibc??) there may be yet more libraries to resolve.

What's the best strategy for solving this? I am guessing I need to identify the libraries needed (how?), find them, and force the program to use them (how? overriding LD_LIBRARY_PATH ?)

Thanks!

Edit: using ldd datab2txt gives the error not a dynamic executable. Uhoh.. what does that mean?

Additionally, I ran file and got:

% file datab2txt

datab2txt: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, for GNU/Linux 2.4.0, not stripped

Answer 1

Identifying the libraries is done with ldd. Finding them is another problem, but try digging around on packages.ubuntu.com for older Ubuntu releases. Then you're looking at unpacking the packages manually and installing the shared objects into their own dedicated directory (or directory tree if needed) and using LD_LIBRARY_PATH to point to them. (Note: using apt-get or dpkg won't work, and if you try to force the issue you might break your system. Just don't.)

Answer 2

You're in luck, there is a command for finding out which libraries a binary needs, with versions expected:

ldd -v /path/to/binary

Answer 3

In theory, using a chroot should do the trick for running the software - one of the situations its designed for is to run unsupported, old software with unsupported ABIs- you will likely need the old box to copy the required libraries from, or find and compile the necessary libraries yourself.

Answer 4

You have a static binary. In general this means all libraries are compiled-in and the binary doesn't have external dependencies. There is however an exception, if a program uses NSS library (libnss).

From https://gcc.gnu.org/ml/gcc/1998-12/msg00083.html:

{AJ} NSS (for details just type `info libc "Name Service Switch"') won't work properly without shared libraries. NSS allows using different services (e.g. NIS, files, db, hesiod) by just changing one configuration file (/etc/nsswitch.conf) without relinking any programs. The only disadvantage is that now static libraries need to access shared libraries. This is handled transparently by the GNU C library.

You would see the following warning, if program uses NSS and you try to compile it statically

> gcc t.c -Wall -static -o hostname -DWITH_NSS
/tmp/cco4Lcky.o: In function `main':
t.c:(.text+0x66): warning: Using 'getaddrinfo' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking

I am not sure there is a simple way to solve this if you have only a binary. Of course, you could find a Linux distribution with an older glibc.