I'm trying to get a system up and running, and am having problems with the OpenMotif shared libraries. I have their directory in LD_LIBRARY_PATH, but it still can't find them.
Here's an example:
[root@intrepid netcool]# ldd /opt/netcool/omnibus/platform/linux2x86/bin/nco_* |grep 'not found'
libXm.so.3 => not found
libXpm.so.4 => not found
libXm.so.3 => not found
libXm.so.3 => not found
libXpm.so.4 => not found
libXm.so.3 => not found
libXm.so.3 => not found
libXm.so.3 => not found
libXm.so.3 => not found
[root@intrepid netcool]# find /usr/ -name libXm.so.3
/usr/lib64/libXm.so.3
[root@intrepid netcool]# find /usr/ -name libXpm.so.4
/usr/lib64/libXpm.so.4
[root@intrepid netcool]# echo $LD_LIBRARY_PATH
/opt/netcool/omnibus//platform/linux2x86/lib/:/opt/netcool//platform/linux2x86/lib/:/usr/lib/:/usr/lib64/
I'm probably doing something stupid, but I can't think of anything else to try.
EDIT: To answer a couple of the questions asked below:
[root@intrepid netcool]# export LD_LIBRARY_PATH
[root@intrepid netcool]# ldd /opt/netcool/omnibus/platform/linux2x86/bin/nco_* |grep 'not found'
libXm.so.3 => not found
libXpm.so.4 => not found
libXm.so.3 => not found
libXm.so.3 => not found
libXpm.so.4 => not found
libXm.so.3 => not found
libXm.so.3 => not found
libXm.so.3 => not found
libXm.so.3 => not found
[root@intrepid netcool]# ldconfig
[root@intrepid netcool]# ldd /opt/netcool/omnibus/platform/linux2x86/bin/nco_* |grep 'not found'
libXm.so.3 => not found
libXpm.so.4 => not found
libXm.so.3 => not found
libXm.so.3 => not found
libXpm.so.4 => not found
libXm.so.3 => not found
libXm.so.3 => not found
libXm.so.3 => not found
libXm.so.3 => not found
Ok, just tried to run one of the executables:
# ./bin/nco_xigen
/opt/netcool//omnibus/platform/linux2x86/bin/nco_xigen: error while loading shared libraries: libXm.so.3: wrong ELF class: ELFCLASS64
Is this a 32 bit/64 bit thing?
The LD_LIBRARY_PATH environment variable tells Linux applications, such as the JVM, where to find shared libraries when they are located in a different directory from the directory that is specified in the header section of the program.
In your terminal, type the following sudo ldconfig and press enter on your keyboard. Close all your open terminals that you were using then open a new terminal session and run echo $LD_LIBRARY_PATH If you see the path you added is echoed back, you did it right.
LD_LIBRARY_PATH is the default library path which is accessed to check for available dynamic and shared libraries. It is specific to linux distributions. It is similar to environment variable PATH in windows that linker checks for possible implementations during linking time. Follow this answer to receive notifications.
Did you export LD_LIBRARY_PATH? the export
keyword tells Bash to send any variables to subprocesses - otherwise ldd will never see LD_LIBRARY_PATH.
The binaries I had were looking for the 32-bit versions of the shared libraries, I had the 64-bit installed. Stupid mistake. LDD didn't produce a very insightful error message, but the binary did when I tried to run it.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With