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 >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. |