Program on ARM cannot find shared library while ldconfig finds it

Question

I have compiled my own shared library "libgsttest.so" which I put in /usr/lib/test

/usr/lib/test/libgsttest.so

I added a file "test.conf" in /etc/ld.so.conf.d containing one line:

/usr/lib/test

the I run ldconfig. To check whether ldconfig found the library, i run:

ldconfig -p | grep test
libgsttest.so (libc6) => /usr/lib/test/libgsttest.so

This shared library is used by a gstreamer plugin (but my guess is that that doesn't really matter to the problem). When I start my plugin, linux protests:

Could not load plugin file: Opening module failed: libgsttest.so: cannot open shared object file: No such file or directory

any ideas why my program cannot find my .so while ldconfig finds it?

EDIT: I have the exact same configuration running on an Opensuse 13.1 with an intel processor where I have no problems!

EDIT 2: some more details on my configuration:

• OpenSuse 13.1 - Intel - 64 bit OS.
• ARM Opensuse 13.1 inside qemu emulation (on the OS mentioned above); so this is not a native arm OS...

EDIT 3: I am sure the library is in the correct format: since putting it in /usr/lib and running ldconfig fixes the problem. The real question remains: why doens't my program find it when it's in the subdir?

Answer 1

I just found a workaround which seems to have helped:

I put my library in /usr/lib/ and ran ldconfig --> everything works

I remove my library from /usr/lib --> everything keeps working.

Maybe ldconfig tries to be too smart; and didn't notice any changes in /usr/lib/test/ since it wasn't tracking this folder before. By changing something in /usr/lib/ I might have forced him to do a real refresh?

Answer 2

http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html

ldconfig doesn't set up the linker names; typically this is done during library installation, and the linker name is simply created as a symbolic link to the ``latest'' soname or the latest real name. I would recommend having the linker name be a symbolic link to the soname, since in most cases if you update the library you'd like to automatically use it when linking. I asked H. J. Lu why ldconfig doesn't automatically set up the linker names. His explanation was basically that you might want to run code using the latest version of a library, but might instead want development to link against an old (possibly incompatible) library. Therefore, ldconfig makes no assumptions about what you want programs to link to, so installers must specifically modify symbolic links to update what the linker will use for a library.