Differences between static and dynamic Databases

Differences between static and dynamic libraries-general Linux technology-Linux programming and kernel information. For more information, see the following. File Preview
The file directory tree is as follows, which is very simple as you can see.
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, make the static library liblt..
1. $ gcc-o lt. o-c lt. c
2. $ ar cqs liblt. a lt. o

Furthermore, links,
1. $ gcc test. o liblt. a-o test

Now let's look at his reference library.
1. $ ldd test
2. linux-gate.so.1 => (0xffffe000)
3. libc. so.6 =>/lib/libc. so.6 (0xb7e29000)
3./lib/ld-linux.so.2 (0xb7f6e000)

Dynamic library
Liblt. so is a dynamic library.
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 Connection Library (let the connector generate a T-type export symbol table, and sometimes generate a weak connection W-type export symbol). External programs cannot connect without this sign. Equivalent to an executable file
-FPIC: indicates that the compiled code is in a separate position. If this option is not used, the compiled code is location-related. Therefore, during dynamic loading, the code is copied to meet the needs of different processes, but cannot achieve the purpose of truly sharing code segments.

-L.: indicates that the database to be connected is in the current directory.
-Ltest: an implicit naming rule is used by the compiler to search for a dynamically connected database. That is, add lib before the given name and. so to determine the library name.
LD_LIBRARY_PATH: The environment variable indicates the path where the dynamic connector can load the dynamic library.

Link Method I. Copy it to the system repository and then link it to gcc to find it by yourself.

1. $ sudo cp liblt. so/usr/lib
2. $ gcc-o test. o-llt
Here we can see the-llt option,-l [lib_name] specifies the library name, and he will actively search
Lib [lib_name]. so. The search path can be searched through gcc -- print-search-dirs.

Link Method II: manually specify the library path

1. $ cc-o test. o-llt-B/path/to/lib

Here, the-B Option adds/path/to/lib to the gcc search path. In this way, the link is okay, but the program manually linked in method II still needs to specify the library path during execution (the link and execution are separated ). System to be added
Unified variable LD_LIBRARY_PATH:


1. $ export LD_LIBRARY_PATH =/path/to/lib

At this time, check the database connection 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 liblt. so more than a static link program? Well, this is the biggest difference between static and dynamic. In static scenarios, he loads the library directly into the program, while in dynamic connections, he only keeps the interface, separate the dynamic library from the program code. In this way, the code reusability can be improved and the coupling degree of the program can be reduced.

In addition, when running, ensure that the main program can find the dynamic library, so the dynamic library is generally released to the system directory, or it is in a relatively fixed path with the main program, in this way, the dynamic library can be found no matter when and where the main program runs on the local machine. When the static library only acts on the link and runs the main program, the static library file does not make sense.