Assume that a program needs a shared library(bar.so) under the folder /usr/lib/foo. I understand if the bar.so was directly under /usr/lib, it would be automatically found. But as in my case the library could not be found automatically, because -I think so- it is under the folder /usr/lib/foo. However there are tons of other folders under /usr/lib and the corresponding programs using those libraries are working seamlessly.
So, how does this process work and how can I fix my issue?
Thanks.
Individual programs can control where they search for their libraries.
Also the search path can be controlled using the LD_LIBRARY_PATH env var:
http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html
Try appending /usr/lib/foo to your LD_LIBRARY_PATH env var.
Related
I have an excutable and a shared library in same directory, the executable running well, however, after moving the shared library to other pos, I can not run the executable showing can not find libxxx.so
I want to know why it happens?
You can move the library to some standard library path. It is defined in /etc/ld.so.conf. The loader will only find libraries defined in there. In the other hand, you can also use LD_LIBRARY_PATH env variable to put your shared library path. It makes sure the path is searched first
When I install a program using apt-get install, it tells me which dependency libraries also need to be installed.
For example, Nginx requires libgd3 (3d graphics library) to be installed.
When Nginx needs to call code in libgd3 how does it know where the file is and
How does it actually go about it? I assume it must load it into the Nginx process heap and then use some kind of function table to make calls?
I am not sure how this process works, thanks.
The libraries are in standard path usually /usr/lib which the linker searches during linking. The dynamic libraries are called shared objects in linux having the extension .so .
Check this link to know more about Linux Libraries:
http://www.yolinux.com/TUTORIALS/LibraryArchives-StaticAndDynamic.html
Usually through the environment variable LD_LIBRARY_PATH which is set of directories where libraries should be searched for first
See what it is set to :
env | grep LD_LIBRARY_PATH
You can update the new location to search temporarily by
export $LD_LIBRARY_PATH = $LD_LIBRARY_PATH:/new/dir/to/look
There is every chance that this env variable is not present in your distro. So you can try the below
1) Add library directories to /etc/ld.so.conf or
2) add it to the library cache by using ldconfig
Please read more here
http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html
On a Linux system, I am trying to run a Fortran program that makes use of some shared libraries (netCDF libs, if that makes a difference). Before I run, I set LD_LIBRARY_PATH so that it points to the location of my libraries. Then I run the executable and I quickly get the error
../my_program: error while loading shared libraries: libnetcdff.so.5: cannot open shared object file: No such file or directory
Now, I double check the value of LD_LIBRARY_PATH, and then cd to it and find plain as day
$ ls *ff*
$ libnetcdff.a libnetcdff.la libnetcdff.so libnetcdff.so.0 libnetcdff.so.0.0.0
So the libnetcdff is absolutely present.
Could anyone point me to the problem?
The one thing that has occurred to me is that the executable seems to want to find libnetcdff.so.5, while the library that is present is actually libnetcdff.so.0. Is that the problem? If so, is there a way to convince the executable to not insist on "5"? Alternatively, would a link from libnetcdff.so.0 to libnetcdff.so.5 solve the problem? (I don't have permissions in the directory, BTW, which is why I haven't tried that yet.)
Environment info: CentOS machine, code compiled with gfortran. And yes, when I compiled, my -L flags were pointing to the same directory that LD_LIBRARY_PATH points to.
Thanks.
A library link should work. Since you mention that you do not have root/sudo access, what you can do is link in a file you do have access in:
ln -s /path/to/libnetcdff.so.0 /path/you/have/access/to/libnetcdff.so.5
And then add in the /path/you/have/access/to/ in your LD_LIBRARY_PATH.
I've got a problem with shared libraries and gcc. At first I couldn't run my compiled program because I was getting the following error: gcc error while loading shared libraries.
I did some searching and found that this is because the shared library cannot be found. However I had already identified that the shared library is in /usr/local/lib, which AFAICT is a commonly used directory for shared libraries and should work from the get go.
I read that you can set LD_LIBRARY_PATH, which worked for me. However I do not wish to set this each time I want to run my program.
Further searching suggested editing ld.so.conf. When I looked in this it had the following:
include /etc/ld.so.conf.d/*.conf
Looking in the ld.so.conf.d directory shows me a range of files, including libc.conf. Inside this file is the following:
/usr/local/lib
So my question is, why do I need to manually set LD_LIBRARY_PATH when the ld.so.conf appears to use the libc.conf which includes /usr/local/lib?
Is there something that I'm missing here that must be configured first? Is there an option at compile time that I'm missing?
I should note that to compile, I had to specify the path to the library, I don't know if this is a symptom of my problem or normal behaviour.
I should also note that this is a concern for me for when I deploy my software on other systems. I would have thought that I should be able to put the .so in the appropriate place and install my program without messing with ld.so.conf.
I hope this is the proper forum for this question, I read the FAQ and I think it's ok.
Cheers.
You should run ldconfig (as root) after every change of the directories configured via /etc/ld.so.conf or under /etc/ld.so.conf.d/, in particular in your case after every update inside /usr/local/lib (e.g. after every addition or update of some shared libraries there).
I have some shared/dynamic libraries installed in a sandbox directory. I'm building some applications which link agains the libraries. I'm running into what appears to be a difference between OSX and Linux in this regard and I'm not sure what the (best) solution is.
On OSX the location of library itself is recorded into the library, so that if your applications links against it, the executable knows where to look for the library at runtime. This works like expected with my sandbox, because the executable looks there instead of system wide install paths.
On Linux I can't get this to work. Apparently the library location is not present in the library itself. As I understand it you have to add the folders which contain libraries to /etc/ld.so.conf and regenerate the ld cache by running ldconfig.
This doesn't seem to do the trick for me because my libraries are located inside a users home directory. It looks like ldconfig doesn't like that, which makes sense actually.
How can I solve this? I don't want to move the libraries out of my sandbox.
On Linux, run your program with the environment variable LD_LIBRARY_PATH set to your sandbox dir.
(I remember having used a flag -R to include library paths in the binary, but either it has been removed from gcc or it was only available on BSD systems.)
On Linux you should set LD_RUN_PATH to your sandbox dir. This is better than setting LD_LIBRARY_PATH because you're telling the linker where the library is at link time, rather than telling the shared library loader at run time.
See: Link