Menu
I can successfully link against libawesomium-1.6.5.so :
-L-L.
-L-lawesomium-1.6.5
-L-ldl
libawesomium-1.6.5.so is in the same directory as my executable, now if I try to call my program (I'll call it prog for now), it exists with:
./prog: error while loading shared libraries: libawesomium-1.6.5.so.0: cannot open shared object file: No such file or directory
So I make a symlink libawesomium-1.6.5.so.0 pointing to libawesomium-1.6.5.so, running prog again gives me the same error, calling it with a custom LD_LIBRARY_PATH=./ works, but I wanna distribute prog and I want the user to be able to use prog with out root-rights (installing awesomium to /usr/lib etc.) and without the need of setting the LD_LIBRARY_PATH. One option would be a shell script which sets the LD_LIBRARY_PATH, but I would prefer a different way (I also heared setting LD_LIBRARY_PATH is a bad idea).
Furthermore, it would be great if there was no need to create the symlink to libawesomium-1.6.5.so.0.
EDIT:
Passing -rpath=. to the linker works! But unfortunatly awesomium can't deal with it:
/.../awesomium_test/AwesomiumProcess: error while loading shared libraries: libawesomium-1.6.5.so.0: cannot open shared object file: No such file or directory
Using -rpath and setting LD_LIBRARY_PATH from inside prog works
757
In Linux, the environment variable LD_LIBRARY_PATH is a colon-separated set of directories where libraries should be searched for first, before the standard set of directories; this is useful when debugging a new library or using a nonstandard library for special purposes.
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.
The PATH environment variable specifies the search paths for commands, while LD_LIBRARY_PATH specifies the search paths for shared libraries for the linker. The initial default values of PATH and LD_LIBRARY_PATH are specified in the buildfile before procnto is started.
ld simply does not perform any lookup under /home/me/root . The contents of LD_LIBRARY_PATH simply never appear in the output, which suggests that ld is shamelessly ignoring the variable (and actually, my directory never appears in SEARCH_DIR earlier in the output).
If you use gcc, you can pass -Wl,-rpath=lib_directory in order to make the executable to search the libraries in the directory lib_directory.
Moreover, this argument accepts a special value $ORIGIN that represents the directory containing the executed program. So if you pass -Wl,-rpath='$ORIGIN' to gcc you will be able to keep libawesomium-1.6.5.so in the same directory than the program.
90
The error is because . is not in your path. Your options are to distribute a bash script which runs the binary with LD_LIBRARY_PATH set, as you say, or to copy the shared object to /usr/lib or /usr/local/lib or wherever suitable on that particular platform.
There is really no shortcut, unless you want to link statically.
33
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
