In-depth research on Linux libraries

Linux operating system, the Linux library file path is still more commonly used, so I studied the Linux library file path, here to share with you, hope to be useful to everyone.

Library files are used when connecting (static libraries and shared libraries) and running (limited to programs that use shared libraries), and their search paths are set in the system. The general Linux system/lib and/usr/lib two directories as the default library search path, so using the libraries in these two directories does not need to set the search path can be used directly. For libraries that are outside the default library search path, you need to add the location of the library to the search path of the library. There are two ways to set the search path for a library file, which can be used as one of the following:

1. Specify the search path of the library in the environment variable Ld_library_path.

2. Add the search path to the library in the/etc/ld.so.conf file.
It's a good idea to add the path you might have in your Linux library file to/etc/ld.so.conf.
Adding a method is also extremely simple, the absolute path of the library file is written directly into the OK, one line. For example:
/usr/x11r6/lib
/usr/local/lib
/opt/lib

It is important to note that the second search path is set up in a way that is sufficient for the location of the library (including shared libraries and static libraries) when the program is connected, but is not sufficient for the execution of programs that use shared libraries. This is because in order to speed up the location of shared libraries during program execution, and to avoid the inefficient use of search paths to find shared libraries, it is straightforward to read the library list file/etc/ld.so.cache from which to search. /etc/ld.so.cache is a non-text data file that cannot be edited directly, it is based on the search path set in/etc/ld.so.conf by/sbin/ldconfig command to set the shared library files under these search paths together (the Ldconfig command is executed with root permission). Therefore, in order to ensure the location of the library when the program executes, after setting the library search path in/etc/ld.so.conf, you must also run the/sbin/ldconfig command to update the/etc/ld.so.cache file. Ldconfig, simply put, it is the role of the/etc/ld.so.conf listed in the path of the library file cache to/etc/ld.so.cache for use. So when you finish installing some Linux library file paths (for example, just install glib) or modify ld.so.conf to add a new library path, you need to run the/sbin/ Ldconfig so that all the library files are cached into the ld.so.cache, if not, even if the library file is clearly under the/usr/lib, but also will not be used, the results of the compilation process, missing the XXX library, to see the discovery clearly in that place, Do want to scold computer stupid pig A.

When the program is connected, the search path for the Linux library files (static libraries and shared libraries) can be explicitly specified with the-l parameter in addition to the above settings. Because the path set with-L is prioritized, the path to the library to which you want to connect is typically specified in this way when you connect.

As explained earlier, there are two ways to search for a path to a Linux library file: Set in environment variable Ld_library_path and in the/etc/ld.so.conf file. The second setting requires root permission to change the/etc/ld.so.conf file and execute the/sbin/ldconfig command. Also, when the system restarts, all GTK2-based programs will use the newly installed GTK + library at run time. Unfortunately, due to the changes in the GTK + version, this can sometimes be a compatibility issue for applications, causing some programs to run abnormally. To avoid these cases, the setting of the search path for the library during the installation of GTK + and its dependent libraries takes the first approach. This setting does not require root privileges and is simple to set up:
$ export ld_library_path=/opt/gtk/lib: $LD _library_path
You can use the following command to view the contents of the Ld_libray_path settings:
$ echo $LD _library_path
At this point, the two settings for the library are complete.

The above is to explain the Linux library files, about how to add their own library file path in the Linux system.

----------------------------------------------------------------------

The following article is very well written.

After the common people raised about the library of various problems, today I can not restrain, according to their own experience, experiments, learning to get some, to say their own point of view. We all know that the library is important to the system. Without it, the system is almost impossible to operate, including LFS the entire process is at least adjusted to the tool chain to adjust the process is based on the library's reliance as the core. This is the essence of the dynamic library. Let's start with a simple static library. It's simply a collection of target files for AR packaging, so it's not exactly the same as the target file, the link into the target file, OK, mission completion, as for the future of the program, including the operation and the static library is not related. Actually, I think the most convincing is an example. , let's give the simplest example. Cat >say.c<<eof #include "stdio.h" void Say () { printf ("say!"); } Eof Cat >test.c <<eof #include "stdio.h" void Say (); Main () { Say (); } Eof Gcc-c say.c Ar-r say.a SAY.O GCC test.c say.a-o Test LDD test The output allows us to see no relationship with SAY.A, the static library we write ourselves. This static library is not needed when the program is running, it has been linked into the final program by LD. So the dynamic library, we continue to gcc-fpic-shared Say.c-o say.so GCC test.c say.so-o Test LDD test If there is no accident, there will be say.so and not found./test is not able to run at this time. But at least the program runtime needs this library. Then why can't I find the library? Then let's see how the system looks for these libraries. The first is ld-linux.so.2 this cannot but say, it is too important, so that also decided the back of the search method. First of all, within the procedure. Strings Test Fortunately we this test program is not big, do not filter output, good, you see what,/lib/ld-linux.so.2,say.so,libc.so.6, right, used to the library! But we found that different, some have a path, some no, first, no matter how to find the path, there is a path is sure to find, that good, we let say.so also have a path. GCC test.c./say.so-o test2 Strings Test2 We found that the original say.so in the original output has become./say.so. Run it./test2, you can run it! Well, find the library, here with the relative path, no doubt, We moved the say.so to a non-current folder. That test is not going to work anymore. This is undoubtedly the library we used to hard code into the program. I don't like hard coding, too rigid. That hard-coded system how to find the files we need. If the program does not hard code the library address in the premise, the system will look for the address in the LD_LIBRARY_PATH environment variable. ld_library_path=././test2 As we wish, the program runs normally. If the system does not find the library we need in this step. /etc/ld.so.cache this ldconfig-generated file records all the library paths indicated in the/etc/ld.so.conf file plus information about all the libraries in the/lib,/usr/lib. In fact, the above sentence is only correct in most cases, whether this document is determined by ld-linux.so.2. If the first tool chain/tools in your LFS, Strings/tools/lib/ld-linux.so.2|grep etc The output is likely to be/tools/etc/ld.so.cache. Then which of the files it uses is clear to us. But what does the/tools in front of this path relate to? First we may think about the location of the ld-linux. Fortunately we have 3 sets of glib, thanks to LFS, now we take the second tool chain. Suppose our lfs in/lfsroot Strings/lfsroot/lib/ld-linux.so.2 It's strange that the output is/etc/ld.so.cache!. So what's this about, exactly, when we compile the--prefix. Now look at this/etc/ld.so.conf, and/lib,/usr/lib these default ldconfig paths. Add a prefix to this. Strings/tools/sbin/ldconfig|grep etc Strings/tools/sbin/ldconfig|grep/lib Check it out. What if the address of the library is not recorded in Ld.so.cache? Finally, find it in the default path. This path is generally/lib,/usr/lib, but not all. Strings/tools/lib/ld-linux.so.2|grep/lib Still need to add a prefix. Now we are thinking in turn, not using the hard-coded/lib/ld-linux.so.2 in the program to do the dynamic loader. Yes, although not necessarily successful. Ld_trace_loaded_objects=y/tools/lib/ld-linux.so.2/bin/test Ld_trace_loaded_objects=y/lib/ld-linux.so.2/bin/test Ld_trace_loaded_objects=y/lfsroot/lib/ld-linux.so.2/bin/test Try to compare the results. No surprises. The first is a library that is searched in/tools/lib, and two or three are libraries in the/lib. Cause I think it's clear. Here's a second example to illustrate the problem: ld_library_path=.//tools/lib/ld-linux.so.2./test /tools/sbin/ldconfig./;/tools/lib/ld-linux.so.2./test CP./say.so/tools/lib/;/tools/lib/ld-linux.so.2./test Three methods should appear the results we want, here is the meaning of/tools/lib/ld-linux.so.2 here, is to use/tools/lib/ld-linux.so.2 this to do dynamic loader. Do not believe to remove this, the latter two methods must not be. Because of the. /test himself hard coded into the/lib/ld-linux.so.2, is not to tube/tools/etc/ld.so.cache, and/tools/lib under the library. To illustrate the order, we do the following very dangerous experiments: Ldconfig/lfsroot/lib; Ldconfig-p There will be a lot of content, but do not try to filter, because the system should be a lot of programs can not be run. You will find that many libraries appear two times/lfsroot/lib, and/lib and/lfsroot/lib in front, stating Ldconfig first processing the address of the parameter, The last is the default address. But the order is not necessarily, should also and compile glibc when our parameter--enable-kernel (I guess according to various performance). Add the export ld_library_path=/lib environment variable in front, can not run the program to run again, indicating that the priority of the Ld_library_path variable is better than Ld.so.cache unset Ld_library_path Echo >/etc/ld.so.cache Ldconfig-p There should be nothing at all, but most of the programs can run. The default path that ld-linux.so.2 determines is useful (note that the default path for Ldconfig here does not work) Ldconfig Recovery system is normal. If you would like to, you can chroot/lfsroot, then do a similar operation to see what is different. Understand the principle we will apply it. Take./test2 as an example. We've changed the library!!! Cat &GT;SAA.C <<eof #include "stdio.h" Say () { printf ("I can do something here!!!"); } Eof gcc-fpic-shared Saa.c-o saa.so Sed "s#\./say\.so#./saa.so#" Test >test3 ./test3 Let's see the results! It's amazing, if it's a setuid program ... In fact, this is very difficult, because this kind of procedure we generally can not write (to their own destruction does not count). This also makes sense of why the authority of the SETUID program has long been so valued----because it is too dangerous. After the surprise you may think, for the non-hard code library address of the program, we directly changed the Ld_library_path is not OK?! Point to our address, use our library, and then ... There is no need to change any files, what to write permission. Oh, to really so easy our lovely Linux is not too fragile, this is afraid to play big, but also you and I do not want to see. So, ld-linux.so.2 early to make restriction, setsid procedures, Ld_library_ The path variable does not work. But the document still has a role to play. Finally, to say the difference between LD, and Ld-linux.so.2, a compile-time, a runtime, LD is responsible for finding the required library in its search path, and to see if there is a required symbol (such as a function), if any, to record the relevant information into the program, This library is found by ld-linux.so.2 at execution time, and the need for symbolic relocation is based on relevant information. Note the way that the search libraries are different. Lc_all=c LD--verbose|grep Search-i Shows its default lookup address. We can do an experiment. Generally, it will have a path similar to I686-pc-linux-gnu/lib, and it is not in the ld-linux.so.2 search path. The rest is that we compile--with-lib-path and lib_ specified by the PATH variable. mv./say.so xxxx/i686-pc-linux-gnu/lib/libsay.so Gcc-o Test4-lsay test.c LDd./test4 The result must be that libsay.so can't find it.