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