In-depth consideration of linuxso Library

An in-depth consideration of the linuxso library-general Linux technology-Linux programming and kernel information. The following is a detailed description. Author: Skymoon. I often see people talking about database issues. Today I can't help myself. based on my own experience, experiment, and learning, I have gained some ideas.
We all know that libraries are important to the system. without it, the system is almost impossible to run, including LFS. At least the tool chain adjustment process is centered on library dependencies. the dynamic library is the essence.
Let's start with a simple static library. it is simply a set of ar-packed target files, so its role is no different from that of the target file. It links to the target file, OK, and the mission is completed, the subsequent tasks of the program, including running, are irrelevant to the static library. in fact, the most convincing thing I think is the example. Let's take the simplest example.
Cat> say. c < # Include "stdio. h"
Void say ()
{
Printf ("Say! ");
}
Eof
Cat> test. c < # 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 results make us unable to see any of them. a: The relationship between our own static databases. it indicates that the static library is no longer needed when the program is running. It has been linked to the final program by ld.
Then, the dynamic library will continue.
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 a say. so => not found. at this time. /test cannot be run. but at least it indicates that the Library is required for running the program. why can't I find this database? Let's see how the system looks for these databases.
First of all, ld-linux.so.2, this can not be said, it is too important, so that it also determines the way to search.
First, it is determined by the program.
Strings test
Fortunately we test program is not big, do not need to filter the output, good, you see what,/lib/ld-linux.so.2, say. so, libc. so.6, right, used library!
However, we find that there are different paths, and some do not. No matter how we look for paths, we can certainly find paths. Well, let's make say. so have a path.
Gcc test. c./say. so-o test2
Strings test2
We found that the original say. so in the original output has been changed to./say. so. Run./test2 and you can run it! Well, I found the database. The relative path used here is undoubtedly, we will say. so move to a non-current folder. then test cannot run again. this will undoubtedly add the library we used into the program. I don't like hard coding. It's too rigid. how does the hard coding system find the files we need.
If the program does not hardcode the library address, the system will find 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 at this step.
/Etc/ld. so. cache, a file generated by ldconfig, is recorded in/etc/ld. so. add the/lib,/usr/lib information to all the library paths specified in the conf file.
In fact, the above statement is only true in most cases, whether this file is determined by the ld-linux.so.2. If your LFS's first tool chain/tools is still there,
Strings/tools/lib/ld-linux.so.2 | grep etc
The output is probably/tools/etc/ld. so. cache. Then, let's know which file it uses.
But what is the relationship between/tools in front of this path? First, we may think about the location of ld-linux. fortunately, we have three sets of glib. Thanks to LFS. Now we can start with the second tool chain. assume that our LFS is at/lfsroot
Strings/lfsroot/lib/ld-linux.so.2
It is strange that the output is/etc/ld. so. cache! So what exactly does this have to do with it? That's right, it's about -- prefix during compilation.
Now let's look at the default ldconfig paths/etc/ld. so. conf,/lib,/usr/lib, and add this prefix.
Strings/tools/sbin/ldconfig | grep etc
Strings/tools/sbin/ldconfig | grep/lib
Verify it.
What if the address of this library is not recorded in ld. so. cache.
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
You still need to add a prefix.
Now we think in turn, do not use the program hard-coded/lib/ld-linux.so.2 dynamic loader. This can also be ?! 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.
The first one is to search for the library in/tools/lib, and the second and third are all in the/lib library. The reason is clear.
The following uses the 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/;/tool/lib/ld-linux.so.2./test
The three methods should all show the results we want, here/tools/lib/ld-linux.so.2 here meaning, is to use/tools/lib/ld-linux. so.2 this is a dynamic loader. do not remove this. The last two methods will not work. because. /test hard-coded into/lib/ld-linux.so.2, is not to manage/tools/etc/ld. so. cache, And.

To illustrate the sequence, we will conduct the following dangerous experiments:
Ldconfig/lfsroot/lib;
Ldconfig-p
There will be a lot of content, but do not try to filter it, because the system should be unable to run many programs. first step down to observe. you will find that many libraries appear/lfsroot/lib twice, And/lib and/lfsroot/lib are in front of each other. This indicates that ldconfig processes the address given by the parameter first, and finally the default address. but the order is not necessarily the same. It should also be related to our parameter-enable-kernel During glibc compilation (I guess based on various performances ).
When the export LD_LIBRARY_PATH =/lib environment variable is in front of the variable, the program that cannot run can run again, indicating that the LD_LIBRARY_PATH variable has a higher priority than ld. so. cache.
Unset LD_LIBRARY_PATH
Echo>/etc/ld. so. cache
Ldconfig-p
Nothing should appear, but most programs can run. It indicates that the default path determined by the ld-linux.so.2 plays a role (note that the default path of ldconfig here does not work)
Ldconfig
Restore the system to normal.
If you want to do this, you can use chroot/lfsroot and then perform similar operations to see what is different.

After understanding the principles, we will apply them.
Take./test2 as an example.
We changed its database !!!
Cat> saa. c < # 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
Check the results!
It's amazing, if it's a setuid program... in fact, this is also very difficult, because we generally cannot write such a program (do not destroy yourself ). this explains why you have always attached so much importance to the permissions of the setuid program for a long time-because it is too dangerous.
After you are surprised, you may wonder if we can change LD_LIBRARY_PATH to a program without a hard-coded library address ?! Point to our address, use our database, and there is no need to change any file, what write permission is required.
Oh, it's so easy. Our lovely Linux is not so fragile. I'm afraid it's a big deal, and I don't mean to see it. so, the ld-linux.so.2 early to make the limit, setsid program, LD_LIBRARY_PATH variable does not work. however, the file still works.
Finally, let's talk about the difference between ld and ld-linux.so.2, a compilation, a runtime, ld is responsible for finding the required library in its search path, and check whether there is a required symbol (such as a function), if there is, record the relevant information in the program, the ld-linux.so.2 find the library during execution and, based on the relevant information, the system repositions the required symbols. note that the methods for Searching databases are different.
LC_ALL = C ld -- verbose | grep search-I
The default lookup address is displayed. we can make an experiment. it usually has a path similar to i686-pc-linux-gnu/lib, and is not in the ld-linux.so.2's search path. the others are the ones specified by the -- with-lib-path and LIB_PATH variables.
Mv./say. so XXXX/i686-pc-linux-gnu/lib/libsay. so
Gcc-o test4-lsay test. c
Ldd./test4
The result must be missing from libsay. so.