静态库/动态库的 生成与编译链接

This section describes the basic mechanisms by which archives and dynamically linked libraries are built. It will give you some sense of where these libraries come from, as a basis for understanding how they are implemented and linked with your programs. If you are developing a library, you need to know the material in this section.

The following commands: 

cc -c function1.c function2.c function3.c 
ar -r libfoo.a function1.o function2.o function3.o

creates an archive library, libfoo.a, that consists of the named object files. See ar(CP) for details of usage. When you use the -l option to link your program with libfoo.a 
cc -Ldir file1.c file2.c file3.c -lfoo

the link editor incorporatess in your executable only the object files in this archive that contain a function you have called in your program.

Create a dynamically linked library by specifying the -dy -G option: 

cc -dy -G -o libfoo.so function1.o function2.o function3.o

This command creates the dynamically linked library libfoo.so consisting of the object code for the functions contained in the named files. See``Implementation'' for details of compiler option -K PIC.

When you use the -l option to link your program with libfoo.so 

cc -dy -Ldir file1.c file2.c file3.c -lfoo

the link editor records in your executable the name of the dynamically linked library and a small amount of bookkeeping information for use by the system at run time. Another component of the system -- the dynamic linker -- does the actual linking. Note, again, that because dynamic linking was turned on with the -dy option, the above command directs the link editor to search libc.so as well as libfoo.a.

---

NOTE: Because code in a dynamically linked library is not copied into your executable object file at link time, a dynamically linked executable normally uses less disk space than a statically linked executable. For the same reason, code in a dynamically linked library can be changed without breaking executables that depend on it. Even if the dynamically linked C library were enhanced in the future, you would not have to relink programs that depended on it as long as the enhancements were compatible with your code. See ``Checking for run-time compatibility''[ldd] for more information.

---

The dynamic linker would simply use the definitions in the new version of the library to resolve external references in your executables at run time.

You can specify the name of the dynamically linked library that you want to create under the -G option. The following command, for example, will create a dynamically linked library called a.out by default: 

cc -dy -G function1.o function2.o function3.o

You can then rename the dynamically linked library to libfoo.so: 

mv a.out libfoo.so

As noted, you use the lib prefix and the .so suffix because they are conventions recognized by -l, just as are lib and .a for archive libraries. So while it is legitimate to create a dynamically linked library that does not follow the naming convention, and to link it with your program 

cc -dy -G -o sharedob function1.o function2.o function3.o 
cc -dy file1.c file2.c file3.c path/sharedob

we recommend against it. Not only will you have to enter a pathname on the cc command line every time you use sharedob in a program, that pathname will be hard-coded in your executables.

The command line: 

cc -Ldir file1.c file2.c file3.c -lfoo

directs the link editor to record in your executable the filename of the dynamically linked library with which it is to be linked at run time.

---

NOTE: cc links the filename, the last component of a pathname, of the dynamically linked library, not its pathname.

---

When you use the -l option to link your program with a dynamically linked library, not only must the link editor be told which directory to search for that library, so must the dynamic linker (unless the directory is the standard place, which the dynamic linker searches by default). See ``Specifying directories to be searched by the dynamic linker'' for more information about pointing to the dynamic linker. However, as long as the pathname of a dynamically linked library is not hard-coded in your executable, you can move the dynamically linked library to a different directory without breaking your program. You should avoid using pathnames of dynamically linked libraries on the cc command line. Those pathnames will be hard-coded in your executable. They won't be if you use-l. 

Finally, the cc -G command not only creates a dynamically linked library, it accepts a dynamically linked library or archive library as input. When you 
create libfoo.so, you can link it with a library you have already created, such as libsharedob.so: 

cc -dy -G -o libfoo.so -Ldir function1.o \ 
function2.o function3.o -lsharedob

This command arranges for libsharedob.so to be linked with libfoo.so when, at run time, libfoo.so is linked with your program. Note that here you will have to point the dynamic linker to the directories in which both libfoo.so and libsharedob.so are stored.