error while loading shared libraries

[silvan]

Hi

I get the following error message when executing my program from the command line:

./comtest 
./comtest: error while loading shared libraries: libcomdll.so: cannot open shared object file: No such file or directory

The operating system is ubuntu 9.10 64bit and the LD_LIBRARY_PATH variable is set to the path were libcomdll.so lies.

Curiously running the program under eclipse with "run..." works fine.

Is there something I have missed?

Cheers,
Silvan

[PanGalactic]

Are you sure that your LD_LIBRARY_PATH points to the location of the right .so file? Most 64-bit Linux systems have both 32-bit and 64-bit libraries installed and it is important that your library path point to the right one.

You can run "strace ./comtest" to see where it is looking and what it is trying to load when this happens.

[ghostpy]

Hi Silvan, first of all I'd recommend that you know exactly what are the libraries that your application needs in order to run, you can accomplish that by issuing the following command: "ldd ./you_app_goes_here"

This would be an example on my machine:

==================================================================
$ ldd ./dist/Debug/SunStudio_12.1-Solaris-Sparc/evaluatortester
libstlport.so.1 => /opt/sunstudio/sunstudio12.1/lib/stlport4/v9/libstlport.so.1
librt.so.1 => /lib/sparcv9/librt.so.1
libCrun.so.1 => /opt/sunstudio/sunstudio12.1/lib/sparc/64/libCrun.so.1
libm.so.2 => /lib/sparcv9/libm.so.2
libthread.so.1 => /lib/sparcv9/libthread.so.1
libc.so.1 => /lib/sparcv9/libc.so.1
libaio.so.1 => /lib/64/libaio.so.1
libmd.so.1 => /lib/64/libmd.so.1
/platform/SUNW,SPARC-Enterprise/lib/sparcv9/libc_psr.so.1
==================================================================

as you can see, ldd outputs a listing of the libraries needed by your app at runtime (note that all of them are dynamic libraries of course), with their corresponding "absolute paths" resolved. If at this moment you see a library with its absolute path UNRESOLVED, your app will crash at some moment during runtime, specifically when it tries to load that unresolved library.

That problem, you can solve in two ways:

1. Finding out the directory where that unresolved library resides, and adding it to the LD_LIBRARY_PATH environment variable, or...

2. Using the "-R<libraries_directory[:libraries_directory]>" option parameter when compiling your application.

The first way is more flexible, as you have the freedom of moving your binary from one machine to another without experiencing any trouble (if the LD_LIBRARY_PATH is setted correctly on both).

The second way is more restricted, but in the other hand, you will be sure of which libraries it will load at runtime, as the absolute path's of the libraries get coded inside of your binary.

Hope this information proves useful :)

Juanjo
Asunción - Paraguay