Linux dynamic library and static library comparison file preview

file directory tree is as follows, as you can see, very simple. 1. libtest/2. | -- lt.c 3. | -- lt.h 4. `-- test.c #lt.c 1. 4. 5. #include 6. 7. void myprint(void) 8. { 9. printf("Linux library test!/n" ); 10. } # lt.h 1. 4. 5. void myprint(void); #test.c 1. 4. 5. #include "lt.h" 6. 7. int main(void) 8. { 9. myprint(); 10. return 0; 11. } First look at the static library first made into the static library liblt.a. 1. $ gcc -o lt.o -c lt.c 2. $ ar cqs liblt.a lt.o Again, link, 1. $ gcc test.o liblt.a -o test This time to see his reference again Library situation. 1. $ ldd test 2. linux-gate.so.1 => (0xffffe000) 3. libc.so.6 => /lib/libc.so.6 (0xb7e29000) 4. /lib/ld-linux. So.2 (0xb7f6e000) The dynamic library is made into the dynamic library liblt.so. 1. $ gcc -o lt.o -c lt.c 2. $ gcc -shared -Wall -fPIC -o liblt.so lt.o -shared This option specifies to generate a dynamic link library (let the connector generate a T type of export) Symbol tables, sometimes also generate weakly connected W type export symbols), can not be connected without the external program. Equivalent to an executable file -fPIC: indicates that the code is compiled as a position-independent code. Without this option, the compiled code is position-dependent, so the dynamic loading is done by code copying to meet the needs of different processes, but not The purpose of real code segment sharing. -L.: indicates that the library to be connected is in the current directory -ltest: The compiler has an implicit naming convention when looking up the dynamic link library, that is, prefixing the given name with lib, followed by .so to determine the library Name LD_LIBRARY_PATH: This environment variable indicates the path that the dynamic connector can load the dynamic library. Link method I, copy it into the system library and link it, let gcc find it yourself. $ sudo cp liblt.so /usr/lib 2. $ gcc -o test test.o -llt Here we can see the -llt option, - l[lib_name] specifies the library name, and he will actively search for lib[lib_name].so. The path to this search can be found by gcc --print-search-dirs. Link Method II, manually specify the library path 1. $ cc -o test test.o -llt -B /path/to/lib The -B option here adds /path/to/lib to the path of the gcc search. There is no problem with this link, but the manually linked program in Method II still needs to specify the library path (link and execution are separate). Need to add the system variable LD_LIBRARY_PATH: 1. $ export LD_LIBRARY_PATH=/path/to/lib This time to check the library link status of the test program (method I) 1. $ ldd test 2. linux-gate.so.1 => ; (0xffffe000) 3. liblt.so => ​​/usr/lib/liblt.so (0xb7f58000) 4. libc.so.6 => /lib/libc.so.6 (0xb7e28000) 5. /lib/ld -linux.so.2 (0xb7f6f000) Well, is there a more liblt.so than a statically linked program? Well, this is the biggest difference between static and dynamic. In static case, he loads the library directly into the program. When dynamically linking, he just keeps the interface and separates the dynamic library from the program code. This can improve the reusability of the code and reduce the coupling of the program. In addition, at runtime, to ensure that the main program can find the dynamic library, so the dynamic library is generally released to the system directory, or in a relatively fixed path to the main program, so that regardless of when the main program runs in the local machine, Can find a dynamic library. When the static library only works on the link, the static library file does not exist when running the main program.