How to debug "cannot open shared object file: No such file or directory"?

Question

On our project at work, where I use a build system managed by another team, I am running into an issue where I am able to compile and link the binary, but then when executing it, it complains about being unable to load a shared object file, it should never have been linked against:

/home/me/build/bin/executable: error while loading shared libraries: libicui18n.so.52.1: cannot open shared object file: No such file or directory

The curious part is, that the only instance of the file name libicui18n.so.52.1 I can even find on my machine are /opt/onlyoffice/desktopeditors/libicui18n.so.52.1 and /home/me/.local/opt/foxitsoftware/foxitreader/lib/libicui18n.so.52.1, which I definitely don't link against, at least according to linker command executed by the build system:

• It does not occur as any of the explicit /absolute/path/to/libsomething.so.42.3 files.
• Nothing related is given as -L option.
• Nothing related is given as /absolute/path/to/libsomething.a file.
• Nothing related is in $LD_LIBRARY_PATH or $LIBRARY_PATH.
• The Intel Fortran compiler has no reason to include those in the default paths.

So now I am wondering, how else the libicui18n.so.52.1 may be linked against, and how I may go about debugging such an issue.

Answer 1

how else the libicui18n.so.52.1 may be linked against

ELF libraries can specify "what name should be used at runtime" independently of the name of the library itself. Example:

gcc -fPIC -shared -o libt.so t.c -Wl,--soname=libfoo.so.1.2.3
gcc main.c -L. -lt

./a.out
./a.out: error while loading shared libraries: libfoo.so.1.2.3: cannot open shared object file: No such file or directory

Here, the library is built in a way which requires libfoo.so.1.2.3 at runtime, although no such library exists. It is up to the packaging system to provide such library (or a symlink).

You can examine a library to see what name it expects to be used at runtime like so:

readelf -d libt.so | grep SONAME
 0x000000000000000e (SONAME)             Library soname: [libfoo.so.1.2.3]

You can examine the list of libraries a.out requires at runtime like so:

 readelf -d ./a.out | grep NEEDED
 0x0000000000000001 (NEEDED)             Shared library: [libfoo.so.1.2.3]
 0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]

how I may go about debugging such an issue.

As above. Your next question is probably "how can I fix this issue?".

Since libicui18n.so.52.1 is installed, but not installed into a directory which the dynamic linker will search by default, all you have to do is tell your binary to add the non-standard /opt/onlyoffice/desktopeditors directory the list of directories to search.

You do that by adding -Wl,-rpath=/opt/onlyoffice/desktopeditors to your executable's link line.

You can also add /opt/onlyoffice/desktopeditors to LD_LIBRARY_PATH, but using -Wl,-rpath is preferred.