Why do I have to define LD_LIBRARY_PATH with an export every time I run my application?

Question

I have some code that uses some shared libraries (c code on gcc). When compiling I have to explicitly define the include and library directories using -I and -L, since they aren't in the standard places. When I try to run the code, I get the following error:

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

However, do the following, everything works just fine:

export LD_LIBRARY_PATH="/path/to/library/"
./sync_test

Now, the strange part is, this only works once. If I try and run sync_test again I get the same error unless I run the export command first. I tried adding the following to my .bashrc, but it made no difference:

LD_LIBRARY_PATH="/path/to/library/"

Solution 1

Use

export LD_LIBRARY_PATH="/path/to/library/"

in your .bashrc otherwise, it'll only be available to bash and not any programs you start.

Try -R/path/to/library/ flag when you're linking, it'll make the program look in that directory and you won't need to set any environment variables.

EDIT: Looks like -R is Solaris only, and you're on Linux.

An alternate way would be to add the path to /etc/ld.so.conf and run ldconfig. Note that this is a global change that will apply to all dynamically linked binaries.

Solution 2

You should avoid setting LD_LIBRARY_PATH in your .bashrc. See "Why LD_LIBRARY_PATH is bad" for more information.

Use the linker option -rpath while linking so that the dynamic linker knows where to find libsync.so during runtime.

gcc ... -Wl,-rpath /path/to/library -L/path/to/library -lsync -o sync_test

EDIT:

Another way would be to use a wrapper like this

#!/bin/bash

LD_LIBRARY_PATH=/path/to/library sync_test "$@"

If sync_test starts any other programs, they might end up using the libs in /path/to/library which may or may not be intended.

Solution 3

You can just put this all on one line:

LD_LIBRARY_PATH="$LD_LIBRARY_PATH:/path/to/library" ./sync_test

Should make things a little easier, even if it doesn't change anything fundamental

Solution 4

Did you 'export' in your .bashrc?

export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:"/path/to/library"

Solution 5

Instead of overriding the library search path at runtime with LD_LIBRARY_PATH, you could instead bake it into the binary itself with rpath. If you link with GCC adding -Wl,-rpath,<libdir> should do the trick, if you link with ld it's just -rpath <libdir>.

View more solutions

Comments

[Admin]

I think all these suggestions are bad - clearly a bug with Linux. Why wont compile time L path was not passed to runtime?

[Flexo]

You can set a path with -rpath, but this is usually not desirably since it then imposes that path on other systems - see second comment on stackoverflow.com/a/695539/168175

[Tom]

This syntax is wonderful... especially if some of your program behavior is based on transient environment variables, such as TMP or TMPDIR

[Tom]

That really doesn't help if you move the application to someone else's machine and they don't want to put the library in the same /path/to that you expected at link time. While -rpath is certainly useful for sysadmins and distro providers, I believe it's presumptuous for an individual to set this.

[Tom]

Although, your first statement "avoid setting LD_LIBRARY_PATH in your .bashrc" I agree with 100%. A middle-ground solution that I have used is a bash script $HOME/bin/myprogram that sets the local LD_LIBRARY_PATH and then runs /path/to/real/myprogram.

[sigjuice]

I agree with the use of a wrapper shell script. I will update my answer.

[Paul Wicks]

Thanks for the tip. None of the things mentioned in the article are really issues in my case (this code is only ever going to be run on one machine by me), but I'll definitely keep them in mind if I ever run into a similar problem.

[Flexo]

-rpath can be problematic, see wiki.debian.org/RpathIssue for a discussion

[jørgensen]

For compatibility, -R is also supported by GNU ld, though as mentioned in the comment by @awoodland, such is undesired. ("Top 10 commercial software mistakes" even, I'd say)

[sigjuice]

@Alcott Yes. -rpath is a GNU ld option. Other linkers might have something similar. -Wl is documented here gcc.gnu.org/onlinedocs/gcc/Link-Options.html and -rpath is documented here sourceware.org/binutils/docs-2.22/ld/Options.html#Options