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

Stonewort

I might need to change the question to something else, but I need suggestions, I'm short on ideas – Stonewort

Hm, I wonder if it's a coincidence that that one's also missing the version number extension - perhaps IPP just isn't installing itself right? – Mombasa

I wonder if the missed library isn't referenced your program, but rather by the libraries that your references? – Chronaxie

@Richard: that's a really good thought. You could possibly compile IPP (or other IPP-dependent libraries) using LD_RUN_PATH or proper linker options. – Mombasa

@Richard: You are probably right, I remember reading something like that and libiomp5.so is a threading library from Intel (IIRC part of MKL). The trouble is that I can't recompile IPP because they are not OSS... – Stonewort

You should absolutely not modify your app's configure.ac/Makefile.am to reflect the non-standard location of the library. Instead, use a CONFIG_SITE file to set LD_LIBRARY_PATH for you at configure time (or just put it in the environment of your login shell, which solves the run-time problem as well). – Pediculosis

The path is expanded through variables set by custom m4 macros that look for the library. There is no "fixed" path in my configure.ac – Stonewort

Answer 1

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!

Stonewort

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)

Mombasa

I modified the question to better specify that I indeed point to a directory. Adding that option to the linking stage did actually solve the problem at compile time, but run time still doesn't work. Of course I did make clean && make to be sure I have updated binaries... – Stonewort

You could try the LD_RUN_PATH route, just in case? – Mombasa

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 LD_LIBRARY_PATH environment variable is an override, so shouldn't be necessary normally.

Soulful

Answer 4

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.

Mooring

Did you look at the information already posted? The OP is using the -R option; the problem is that it's not working as expected. And modifying ld.so.conf is like setting LD_LIBRARY_PATH, except even worse - it applies to everything ever, not just this program, and deploying in a way which always requires root is not easier. – Mombasa

Also, though a wrapper script would work, it's not only inelegant, but in certain unlikely but possible cases, it could be problematic - if the program in question launches other programs, they'll inherit that environment variable, and you're again open to the usual problems with LD_LIBRARY_PATH again. – Mombasa

I'm not saying they're good solutions, but if the end user is installing runtime components that are dependencies and those are not explicitly added to the system's lookup methods, then your options are extremely limited. There are basically only two ways to find dynamic libs outside of the defaults -- you update ld.so, or you use LD_LIBRARY_PATH (or LD_RUN_PATH) in some form. – Mooring

Answer 5

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?

Ossie

Answer 6

bash:

export LD_LIBRARY_PATH=/path/to/lib

tcsh:

setenv LD_LIBRARY_PATH /path/to/lib

Chronaxie

The question is how not to have to set LD_LIBRARY_PATH, not how to set it. This is a very reasonable question, as setting LD_LIBRARY_PATH can be pretty evil. – Mombasa

Answer 7

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

Kaete

That is not a viable option, it would be like setting LD_LIBRARY_PATH, but possibly less portable. Also it would require an administrative task, which doesn't solve the main problem, which is to make as painless as possible for the next user/developer to run the software. – Stonewort