shared object library not found when running program, but it's linked during compiling

Question

Update: issue is solved. The library was Made for Armv7a CPUs but it was "soft float" Not "hard float". It seems like my machine is HF and Not SF compatible

My program depends on an externally build .so library called libMyLib.so. When I compile the program like this:

$ g++ -std=c++11 main.cpp -o run -pthread

it reports that there are a lot of undefined references, obviously because i didn't include libMyLib.so when compiling. So the compiler knows what he needs to compile the program. When i compile the program like this:

$ g++ -std=c++11 main.cpp -o run -pthread -lMyLib

it doesn't report any errors and creates the file "run". Notice that libMyLib.so is already in /usr/local/lib and it looks like it is linked when compiling since the references are defined now and the "run" file is created. But as i run the file, this happens:

$ ./run
    ./run: error while loading shared libraries: libMyLib.so: cannot open shared object file: No such file or directory

I've checked with ldd and it shows me this:

$ ldd run
    ...
    libMyLib.so => not found
    ...

So ldd doesn't find the library on execution, but it finds it while compiling. I'm quite new to Linux and linking libraries so i don't know what to do.

Also, running ldd on the .so file returns this:

$ ldd /usr/local/lib/libMyLib.so
    not a dynamic executable

I've already checked an this message may occur when running a .so file on the wrong platform. But i've checked, the library is compiled for arm (I'm running on a raspberry pi -> arm):

$  objdump -f /usr/local/lib/libMyLib.so | grep ^architecture
    architecture: arm, flags 0x00000150:

I also update the linker:

$ sudo ldconfig -v
...
/usr/local/lib:
    libwiringPi.so -> libwiringPi.so.2.44
    libwiringPiDev.so -> libwiringPiDev.so.2.44
    libMyLib.so -> libMyLib.so.1
...

I really have no clue why this might still happen. Can anyone help me?

Answer 1

/usr/local/lib is one of the directories that the linker searches by default for libraries specified with the -l option, so your linkage succeeds.

At runtime however, the program loader by default searches for the linked libraries in:-

• /lib, /usr/lib and among the libraries whose names and locations have been cached in the ldconfig cache, /etc/ld.so.cache.
• The directories listed in the value of the environment variable LD_LIBRARY_PATH, in the current shell.

The ldconfig cache is only updated when ldconfig is run. See man ldconfig.

The loader fails to find libMyLib.so at runtime because you have not run ldconfig since you placed that library in /usr/local/lib and neither have you correctly added /usr/local/lib to the LD_LIBRARY_PATH in the same shell in which you try to run the program.

It is inconvenient and otherwise undesirable to require a special setting of LD_LIBRARY_PATH to enable a program to run.

To enable the loader to find your library, run ldconfig as root. This will succeed provided that /usr/local/lib is listed in /etc/ld.so.conf, or in one of the files included by /etc/ld.so.conf. If it's not, then you can explicitly cache the shared libraries from /usr/local/lib by running ldconfig /usr/local/lib, as root.