Library path setting in linux

How do you specify the location of libraries to a binary? (linux)

For this question I’ll be using a specific example, but really this generalizes to pretty much any binary on linux that can’t seem to find its’ dependent libraries. So, I have a program that won’t run because of missing libraries:

./cart5: error while loading shared libraries: libcorona-1.0.2.so: cannot open shared object file: No such file or directory 

linux-vdso.so.1 => (0x00007fff18b01000) libcorona-1.0.2.so => not found libstdc++.so.6 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.4.3/libstdc++.so.6 (0x00007f0975830000) libm.so.6 => /lib/libm.so.6 (0x00007f09755af000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00007f0975399000) libc.so.6 => /lib/libc.so.6 (0x00007f0975040000) libz.so.1 => /lib/libz.so.1 (0x00007f0974e2b000) /lib64/ld-linux-x86-64.so.2 (0x00007f0975b36000) 

oliver@human$ find / -name libcorona-1.0.2.so 2> /dev/null /usr/local/lib64/libcorona-1.0.2.so /home/oliver/installed/corona-1.0.2/src/.libs/libcorona-1.0.2.so 

3 Answers 3

For a once-off, set the variable LD_LIBRARY_PATH to a colon-separated list of directories to search. This is analogous to PATH for executables, except that the standard system directories are additionally searched after the ones specified through the environment.

LD_LIBRARY_PATH=/usr/local/lib64 ./cart5 

If you have a program that keeps libraries in a non-standard location and isn’t able to find them on its own, you can write a wrapper script:

#!/bin/sh if [ -n "$LD_LIBRARY_PATH" ]; then LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/lib64 else LD_LIBRARY_PATH=/usr/local/lib64 fi export LD_LIBRARY_PATH exec /path/to/cart5 "$@" 

The list of standard system directories is kept in /etc/ld.so.conf . Recent systems allow this file to include other files; if yours contains something like include /etc/ld.so.conf.d/*.conf , create a new file called /etc/ld.so.conf.d/mala.conf containing the directories you want to add. After you change /etc/ld.so.conf or an included file, run /sbin/ldconfig for your changes to take effect (this updates a cache).

( LD_LIBRARY_PATH also applies to many other unices, including FreeBSD, NetBSD, OpenBSD, Solaris and Tru64. HP-UX has SHLIB_PATH and Mac OS X has DYLD_LIBRARY_PATH . /etc/ld.so.conf has analogs on most unices but the location and syntax differs more widely.)

Источник

Setting Library path in Linux

You need to use ldconfig config file and ldconfig command which creates the necessary links and cache to the most recent shared libraries found in the directories specified on the command line, in the file /etc/ld.so.conf (for Debian distributions), and in the trusted directories such as /lib64 or /usr/lib64 (/lib or /usr/lib on 32 bit systems). The /etc/ld.so.conf contains lib settings which can be used to add or delete paths.

However, you need to simply drop your config file in /etc/ld.so.conf.d/ directory and it will be used by /sbin/ldconfig to configure dynamic linker run time bindings.

Add Your Path

Create a file called /etc/ld.so.conf.d/myapp.conf:

Activate Your Library Path

You must run the following command to activate path:

Verify Your New Library Path

# ldconfig -v | less 
# ldconfig -v | grep /usr/local/lib

/usr/local/lib: libGeoIP.so.1 -> libGeoIP.so.1.4.6 libGeoIPUpdate.so.0 -> libGeoIPUpdate.so.0.0.0 /usr/lib64/mysql: libmysqlclient_r.so.15 -> libmysqlclient_r.so.15.0.0 libmysqlclient.so.15 -> libmysqlclient.so.15.0.0 /lib: libutil.so.1 -> libutil-2.5.so

How Do I Delete The Library Path?

# rm /etc/ld.so.conf.d/myapp.conf # ldconfig

How Do I Edit The Library Path?

Simply edit the file and reload the changes:

# vi /etc/ld.so.conf.d/myapp.conf # ldconfig

How Do I Compile Program With Shared Libs And GNU GCC?

You can use the following gcc:

$ gcc -Wl,-R/path/to/lib -I/path/to/include -L/path/to/lib -o myAppName mycode.c -llibapp2

Add to LD_LIBRARY_PATH

Add the library path you need and set this at shell for temporary use or add to the shell initialization file for permanent effect:

export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/opt/foobar/lib

Check shared libraries used by program

You can see the list of the shared libraries used by a program using ldd. So, for example, you can see the shared libraries used by ls by typing:

Generally you’ll see a list of the sonames being depended on, along with the directory that those names resolve to. In practically all cases you’ll have at least two dependencies:

• /lib/ld-linux.so.N (where N is 1 or more, usually at least 2). This is the library that loads all other libraries.
• libc.so.N (where N is 6 or more). This is the C library. Even other languages tend to use the C library (at least to implement their own libraries), so most programs at least include this one.

Beware: do not run ldd on a program you don’t trust. As is clearly stated in the ldd(1) manual, ldd works by (in certain cases) by setting a special environment variable (for ELF objects, LD_TRACE_LOADED_OBJECTS) and then executing the program. It may be possible for an untrusted program to force the ldd user to run arbitrary code (instead of simply showing the ldd information). So, for safety’s sake, don’t use ldd on programs you don’t trust to execute.

Источник

How to specify preference of library path?

Your solution should work with using the -L/my/dir -lfoo options, at runtime use LD_LIBRARY_PATH to point to the location of your library.

..implications.
Security: Remember that the directories specified in LD_LIBRARY_PATH get searched before(!) the standard locations? In that way, a nasty person could get your application to load a version of a shared library that contains malicious code! That’s one reason why setuid/setgid executables do neglect that variable!
Performance: The link loader has to search all the directories specified, until it finds the directory where the shared library resides – for ALL shared libraries the application is linked against! This means a lot of system calls to open(), that will fail with “ENOENT (No such file or directory)”! If the path contains many directories, the number of failed calls will increase linearly, and you can tell that from the start-up time of the application. If some (or all) of the directories are in an NFS environment, the start-up time of your applications can really get long – and it can slow down the whole system!
Inconsistency: This is the most common problem. LD_LIBRARY_PATH forces an application to load a shared library it wasn’t linked against, and that is quite likely not compatible with the original version. This can either be very obvious, i.e. the application crashes, or it can lead to wrong results, if the picked up library not quite does what the original version would have done. Especially the latter is sometimes hard to debug.

Use the rpath option via gcc to linker — runtime library search path, will be used instead of looking in standard dir (gcc option):

-Wl,-rpath,$(DEFAULT_LIB_INSTALL_PATH) 

This is good for a temporary solution. Linker first searches the LD_LIBRARY_PATH for libraries before looking into standard directories.

If you don’t want to permanently update LD_LIBRARY_PATH you can do it on the fly on command line:

LD_LIBRARY_PATH=/some/custom/dir ./fooo 

You can check what libraries linker knows about using (example):

/sbin/ldconfig -p | grep libpthread libpthread.so.0 (libc6, OS ABI: Linux 2.6.4) => /lib/libpthread.so.0 

And you can check which library your application is using:

ldd foo linux-gate.so.1 => (0xffffe000) libpthread.so.0 => /lib/libpthread.so.0 (0xb7f9e000) libxml2.so.2 => /usr/lib/libxml2.so.2 (0xb7e6e000) librt.so.1 => /lib/librt.so.1 (0xb7e65000) libm.so.6 => /lib/libm.so.6 (0xb7d5b000) libc.so.6 => /lib/libc.so.6 (0xb7c2e000) /lib/ld-linux.so.2 (0xb7fc7000) libdl.so.2 => /lib/libdl.so.2 (0xb7c2a000) libz.so.1 => /lib/libz.so.1 (0xb7c18000) 

Источник

Specify location of static libraries for C++ application in Linux

first of all, I hope that I ask the question in the right context here. I build an application in C++ with Code::Blocks. The application uses static libraries that are provided by a third party and cannot be installed on a system via the package management. Therefore I ship these libraries when I distribute my application. Here is what my target configuration looks like:

I can build this target fine and run it. Everything works. Today, I tried to run in on Debian Squeeze and just copied a folder which contained both the executable and the libraries from the third party. I thought that as long as everything is in one folder the executable will find the .so files. I was wrong. I get the message:

/home/my_app/my_app: error while loading shared libraries: lib1.so: cannot open shared object file: No such file or directory 

I don’t get this message on my developement machine because Code::Blocks is able to set a working directory for the executable. I could remove the error message by putting the location of the .so files inside /etc/ld.so.conf.d/my_app.conf. Is there anyway I can build the executable so it searches the libs in the execution directory? Or this is a problem specific for Debian? Or can I specify the working directory for the process before I execute the executable? I want to avoid changing the systems configuration / environment before you can start the application.

Источник