#91 kid3: error while loading shared libraries: libkid3-gui.so.3.0.2: cannot open shared object file: No such file or directory

[Juan Luis Baptiste]

Hi,

I'm the maintainer in charge of kid3 on Mageia. When running kid3 3.1 on cauldron (the development version), the binary can't find its own libraries:

kid3: error while loading shared libraries: libkid3-gui.so.3.0.2: cannot open shared object file: No such file or directory

If I define LD_LIBRARY_PATH=/usr/lib64/kid3 and then run kid3 it works, this is because the binary doesn't look there for the library:

open("/lib64/tls/x86_64/libkid3-gui.so.3.0.2", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat("/lib64/tls/x86_64", 0x7ffff695de80) = -1 ENOENT (No such file or directory)
open("/lib64/tls/libkid3-gui.so.3.0.2", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat("/lib64/tls", 0x7ffff695de80)      = -1 ENOENT (No such file or directory)
open("/lib64/x86_64/libkid3-gui.so.3.0.2", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat("/lib64/x86_64", 0x7ffff695de80)   = -1 ENOENT (No such file or directory)
open("/lib64/libkid3-gui.so.3.0.2", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat("/lib64", {st_mode=S_IFDIR|0755, st_size=135168, ...}) = 0
open("/usr/lib64/tls/x86_64/libkid3-gui.so.3.0.2", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat("/usr/lib64/tls/x86_64", 0x7ffff695de80) = -1 ENOENT (No such file or directory)
open("/usr/lib64/tls/libkid3-gui.so.3.0.2", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat("/usr/lib64/tls", 0x7ffff695de80)  = -1 ENOENT (No such file or directory)
open("/usr/lib64/x86_64/libkid3-gui.so.3.0.2", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat("/usr/lib64/x86_64", 0x7ffff695de80) = -1 ENOENT (No such file or directory)
open("/usr/lib64/libkid3-gui.so.3.0.2", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat("/usr/lib64", {st_mode=S_IFDIR|0755, st_size=135168, ...}) = 0
writev(2, [{"kid3", 4}, {": ", 2}, {"error while loading shared libra"..., 36}, {": ", 2}, {"libkid3-gui.so.3.0.2", 20}, {": ", 2}, {"cannot open shared object file", 30}, {": ", 2}, {"No such file or directory", 25}, {"\n", 1}], 10kid3: error while loading shared libraries: libkid3-gui.so.3.0.2: cannot open shared object file: No such file or directory

it looks for it on /usr/lib64 (the same happens on x86). I could do a wrapper script that defines LD_LIBRARY_PATH first and then calls kid3, but I suppose there's another reason why this is failing. kid3 2.3 which we have on mga 4 doesn't have this issue, but I haven't taken a look to where it does it install the libraries.

Any ideas ?

[Urs Fleisch]

Kid3 installs its private libraries into a private directory inside the standard library directory (I assume this are /usr/lib/kid3 and /usr/lib64/kid3 in the case of Mageia). To be able to find this libraries, it sets the RPATH in the executables. You can check this using "readelf -d /usr/bin/kid3-qt". On Ubuntu, this shows something like

0x0000000f (RPATH)                      Library rpath: [/usr/lib/kid3]

It is possible that the superordinate build/packaging system of Mageia disables the setting of RPATH, e.g. by setting CMAKE_SKIP_RPATH to TRUE (the CMake doc says CMAKE_SKIP_RPATH: "If this is set to TRUE, then the rpath information is not added to compiled executables."). I have seen this on NetBSD, this is not so unusual because some people consider RPATH harmful. If this it the case in Mageia, you will not see the RPATH output when using readelf.

If RPATH is disabled, you have two possiblities to fix the problem:

• Ignore the CMake system and add an RPATH using some low level methods like "LDFLAGS=-Wl,-R/usr/lib/kid3" or "LDFLAGS=-Wl,-R/usr/lib64/kid3", respectively.

or

• Install the private Kid3 libraries into a directory which is searched by the dynamic linker, e.g. /usr/lib and /usr/lib64. You can do this by using "-DWITH_LIBDIR=/usr/lib" when calling cmake (or "-DWITH_LIBDIR=/usr/lib${LIB_SUFFIX}" or whatever is necessary to make it work for both 32-bit and 64-bit).

[Juan Luis Baptiste]

Hi,

Thanks for the answer, I'm going wih the second option.

[Urs Fleisch]

I have now added a warning message for this case. Note that my advice for using WITH_LIBDIR was not 100% correct, it should be relative to the prefix, i.e. use "-DWITH_LIBDIR=lib" or "-DWITH_LIBDIR=lib${LIB_SUFFIX}".

And now for something completely different: I noticed that the Mageia spec file still uses -D__KDE_HAVE_GCC_VISIBILITY:BOOL=OFF. This should no longer be necessary.

[Urs Fleisch]

Fixed in version 3.1.1.