Linux - SoftwareThis forum is for Software issues.
Having a problem installing a new program? Want to know which application is best for the job? Post your question in this forum.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I have a theoretical question about the linux FS hierarchy and shared libraries.
Sorry, but I come from windows and I think the best way I can ask the question is to explain in windows what I am looking for. In windows there are dlls, in Linux there are blabla.so.version files. If I am not mistaken, these serve similar purposes. In windows, an exe will find a dll if it is in the same directory, or the directory of the dll is in the path.
How does this work in linux? I can see that there are *.so.* files in /usr/local/lib, but the /usr/local/lib is not in the path (on my system).
Is /usr/local/lib hardcoded in the source code? Or is there a separate place to configure the location of shared libraries?
I recently responded to a similar question. Perhaps it will answer your question.
Quote:
When you link programs with libraries, the linker doesn't use the full path to the library; only the library name. The standard libraries to use are /lib and /usr/lib. Any others must be given in the compile command.
At run-time, the system will search only /lib and /usr/lib for the libraries. If they are not found, you get error messages.
To fix that, you need to add "-W1,rpath" option with the path to additional libraries, like so:
g++ -Wall simple_xy_wr.cpp /usr/local/lib/libnetcdf_c++.a /usr/local/lib/libnetcdf.a -W1,rpath,/usr/local/lib.
Now the system should search the standard /lib and /usr/lib, plus /usr/local/lib, at run-time.
Reference: Advanced Linux Programming, ch. 2, section 3.4, Library Dependencies
If you want to run a program which needs a library which is not in the default paths, you can specify $LD_LIBRARY_PATH and $LD_RUN_PATH environment variables. (One of these two... I don't remember now which one... is for running, and other is for compiling.)
For example, I have installed some softwares in a specific directory /tmp/fakeroot (I install everything by compiling it with "./configure --prefix=/tmp/fakeroot"). So I have added following in my bashrc:
When Linux is searching for a library, there are two "trusted" places where it knows to look: /lib and /usr/lib. Any other "places to look" must be identified (by the root user) in the file /etc/ld.so.conf.
Since "looking for things" is actually expensive, Linux builds a cache of the search-results so that actual searching is unnecessary. That's what ldconfig does: it rebuilds the cache.
At runtime, it is possible to (as with Windows) declare "search paths" which applications can refer-to ... over-and-above these system-wide caches and search-paths. These are on a user-by-user and app-by-app basis.
A simple way to find out what libraries a particular app uses:
You can also use:
objdump -p MyBinary | grep NEEDED
This is NOT the same as the ldd program, which dumps a list of every single thing loaded into a process by the ELF file, MyBinary, including dependencies of dependencies. Usually, this list of needed files will be much smaller than the output from ldd.
objdump is part of the GNU binary utilities: the most recent stable version being binutils-2.18.tar.bz2
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.