Changing a binaries linked libraries

piercey · 09-11-2007, 04:09 AM

Hi everyone,

I have a binary file that I compiled on a centos 4.5 distro. I wish to copy this file to another machine (which is a streipped down embedded distro) and run it there, however it obviously has a number of linked libraries which aren't in the same location on that machine or don't exist at all.

Basically, if I run ldd on the library (on the machine it was compiled on) this is the output:

Code:

ldd ddccontrol
       libddccontrol.so.0 => /usr/local/lib/libddccontrol.so.0
(0x005f3000)
       libxml2.so.2 => /usr/lib/libxml2.so.2 (0x02ba5000)
       libz.so.1 => /usr/lib/libz.so.1 (0x00d0c000)
       libpthread.so.0 => /lib/tls/libpthread.so.0 (0x00dd9000)
       libm.so.6 => /lib/tls/libm.so.6 (0x00bf0000)
       libc.so.6 => /lib/tls/libc.so.6 (0x00ac4000)
       /lib/ld-linux.so.2 (0x00aab000)

Now some of those libraries/paths dont exist on the other machine, so I'm looking for a way to just package the binary with the libs, like:

myapp/binary
myapp/lib/libxml2.so.2 etc.

I have tried opening the binary file in a hex editor to change the path but I end up with a seg fault so I assume I'm doing it wrong. Can anyone give me any pointers on how to do this better, perhaps a specific tool i could use or maybe even recommend a hex editor.

Any help is appreciated,

Thanks.

osor · 09-12-2007, 06:02 PM

There are two separate issues here: the first issue is that on the target system, some libraries exist, but may be at a different location. This is ok (as long as the location is in the system library path). This is because the full path to a library is not specified to the binary (under normal circumstances: see rpath later on). The output of ldd shows the library soname specified, followed by an ASCII arrow (“=>”), followed by the location from which the library would be fetched were the executable executed. I’ll illustrate this functionality with an example (NOTE: please don’t use LD_LIBRARY_PATH as a permanent solution. I’m just using it for demonstration):

Code:

$ mkdir -p /tmp/thisisatest
$ cp -L /usr/local/lib/libddccontrol.so.0 /tmp/thisisatest
$ export LD_LIBRARY_PATH="/tmp/thisisatest"
$ ldd ddccontrol
       libddccontrol.so.0 => /tmp/thisisatest/libddccontrol.so.0 (0x005f3000)
       libxml2.so.2 => /usr/lib/libxml2.so.2 (0x02ba5000)
       libz.so.1 => /usr/lib/libz.so.1 (0x00d0c000)
       libpthread.so.0 => /lib/tls/libpthread.so.0 (0x00dd9000)
       libm.so.6 => /lib/tls/libm.so.6 (0x00bf0000)
       libc.so.6 => /lib/tls/libc.so.6 (0x00ac4000)
$ rm -rf /tmp/thisisatest
$ unset LD_LIBRARY_PATH
$ ldd ddccontrol
       libddccontrol.so.0 => /usr/local/lib/libddccontrol.so.0 (0x005f3000)
       libxml2.so.2 => /usr/lib/libxml2.so.2 (0x02ba5000)
       libz.so.1 => /usr/lib/libz.so.1 (0x00d0c000)
       libpthread.so.0 => /lib/tls/libpthread.so.0 (0x00dd9000)
       libm.so.6 => /lib/tls/libm.so.6 (0x00bf0000)
       libc.so.6 => /lib/tls/libc.so.6 (0x00ac4000)
       /lib/ld-linux.so.2 (0x00aab000)

Notice how the first line of output changes upon changing the system’s library lookup path. Ostensibly, this should happen with some of the libraries on the target machine by default (e.g., libc.so.6, libm.so.6, libpthread.so.0, and/or libz.so.1).

The next part of your question regards libraries that don’t exist on the target system (at all). There are many ways to deal with this (among which one of the most discouraged is fiddling with LD_LIBRARY_PATH). If you are compiling the sources by hand, the easiest solution is to link the affected libraries statically (there is little reason to use dynamic libs for only one binary on an small system). Another solution at compile time (assuming you want to use and bundle the shared libraries) is to use runtime path specification. This is either directly or indirectly through ld (directly with “-rpath /path/to/libs” or indirectly through gcc with “-Wl,-rpath,/path/to/libs”). A third method exists if you are unable to recompile. You can use an ELF file modification program to rewrite the runtime path specification. PatchELF is one such program. The final resort (which is often discouraged as it may exhibit unwanted behavior) is to run the resulting binary (on the host system) with the LD_LIBRARY_PATH environment variable set to accommodate the bundled libraries).