How do I get rid of LD_LIBRARY_PATH at run-time?

Question

I am building a C++ application that uses Intel's IPP library. This library is installed by default in /opt and requires you to set LD_LIBRARY_PATH both for compiling and for running your software (if you choose the shared library linking, which I did). I already modified my configure.ac/Makefile.am so that I do not need to set that variable when compiling, but I still can't find the shared library at run-time; how do I do that?

I'm compiling with the -Wl, -R/path/to/libdir flag using g++

Update 1: Actually my binary program has some IPP libraries correctly linked, but just one is not:

$ ldd myprogram
linux-vdso.so.1 =>  (0x00007fffa93ff000)
libippacem64t.so.6.0 => /opt/intel/ipp/6.0.2.076/em64t/sharedlib/libippacem64t.so.6.0 (0x00007f22c2fa3000)
libippsem64t.so.6.0 => /opt/intel/ipp/6.0.2.076/em64t/sharedlib/libippsem64t.so.6.0 (0x00007f22c2d20000)
libippcoreem64t.so.6.0 => /opt/intel/ipp/6.0.2.076/em64t/sharedlib/libippcoreem64t.so.6.0 (0x00007f22c2c14000)
[...]
libiomp5.so => not found
libiomp5.so => not found
libiomp5.so => not found

Of course the library is there:

$ locate libiomp5.so
/opt/intel/ipp/6.0.2.076/em64t/sharedlib/libiomp5.so

Answer 1

bash:

export LD_LIBRARY_PATH=/path/to/lib

tcsh:

setenv LD_LIBRARY_PATH /path/to/lib

Answer 2

By /path/to/lib do you mean path to the directory containing the library, or the path to the actual file?

The -R option given a directory argument is treated like -rpath by ld, which is the option you're actually wanting here. It adds the given directory to the runtime library search path. That should work, as long as you give it the directory and not filename. I'm fairly confident about that, having done it myself, and because it's one of the hints given by libtool:

Libraries have been installed in:

/path/to/library-directory

If you ever happen to want to link against installed libraries in a given directory, LIBDIR, you must either use libtool, and specify the full pathname of the library, or use the `-LLIBDIR' flag during linking and do at least one of the following:

• add LIBDIR to the `LD_LIBRARY_PATH' environment variable during execution
• add LIBDIR to the `LD_RUN_PATH' environment variable during linking
• use the `-Wl,-rpath -Wl,LIBDIR' linker flag
• have your system administrator add LIBDIR to `/etc/ld.so.conf'

(I paste this here since conceivably one of the other options could be more desirable - for example LD_RUN_PATH can save you makefile modification)

Answer 3

You can check if the path to the library is being picked up from your -R flag by running the ldd command or the readelf command on your binary. The env var is an override, so shouldn't be necessary normally.

Answer 4

Try configuring your ldconfig through ld.so.conf so it searches your /opt/... directory by default.

Answer 5

You should use the -R option if possible.

If not, rename your executable and create a launch script that runs your executable, and in there set LD_LIBRARY_PATH just for that scope.

Depending on platform, you can modify ld.so.conf via /etc/ld.so.conf.d (Redhat/Fedora come to mind) which makes deploying changes to ld.so "easier" from a deployment scenario.

Answer 6

Besides all the useful hints posted here.. you're not trying to use a 64-bit specific library on a 32-bit system (or viceversa, depending on other conditions), are you?

Answer 7

As suggested by Richard Pennington, the missing library is not used directly by my application, but it is used by the shared libraries I use. Since I cannot recompile IPP, the solution to my problem is to add -liomp5 when compiling, using the -R option for the linker. This actually adds the rpath for libiomp5.so fixing the problem!