4

I know I have the library, but the executable can't find it. If I knew where it was searching, I could just create a symlink where it expects to find the lib. 

$ ~/Apps/simutrans/simutrans
/home/dan/Apps/simutrans/simutrans: error while loading shared libraries: libbz2.so.1.0: cannot open shared object file: No such file or directory

$ locate libbz2
...
/lib/x86_64-linux-gnu/libbz2.so.1
/lib/x86_64-linux-gnu/libbz2.so.1.0
/lib/x86_64-linux-gnu/libbz2.so.1.0.4
/usr/lib/x86_64-linux-gnu/libbz2.a
/usr/lib/x86_64-linux-gnu/libbz2.so
...

Apparently, the executable isn't using /etc/ld.so.conf* to find libraries; if it was, then it would have found the lib:

$ cat /etc/ld.so.conf.d/x86_64-linux-gnu.conf 
# Multiarch support
/lib/x86_64-linux-gnu
/usr/lib/x86_64-linux-gnu

Inspecting the executable with readelf, as mentioned in where will the system search for dynamic libraries?, doesn't show a RUNPATH entry that would have shown when the library needs to be found.

Dan Ross
  • 615
  • 2
  • 6
  • 14

1 Answers1

5

Assuming your program runs with the current user (no setuid, etc), you can use strace to get this information, e.g.,

strace -o foo.out ~/Apps/simutrans/simutrans

and look in the output file for open calls.

Thomas Dickey
  • 76,765
  • Found it, created a symlink, and now the executable crashes with /home/dan/Apps/simutrans/simutrans: error while loading shared libraries: libbz2.so.1.0: wrong ELF class: ELFCLASS64. Looks like I got handed a 32 bit version. – Dan Ross Dec 12 '15 at 12:58