.ofiles) collected into one file by the
arprogram. Static libraries usually end with
libg++.a). At link time, static libraries are searched for each global function or variable symbol. If the symbol is found then the code for that symbol is copied into the binary. In addition, any other symbols that were in the original
.ofile for the symbol in question are also copied into the binary. In this way, if we need a symbol that is dependent on other functions in the
.ofile in which it is defined, at link time we get the dependent functions. There are several important details about linking, such as the order of libraries, that should be discussed in your system documentation.
Shared libraries allow multiple programs to share a library on disk, rather than copying code into a binary, resulting in smaller binaries. Also shared libraries allow a binary to access all of the symbols in a shared library at runtime, even if a symbol was not needed at link time.
A shared library consists of an archive of object files (
.ofiles) collected into one file by either the compiler or the linker. Usually, to create a shared library, the
.ofiles must be compiled into Position Independent Code (PIC) by the compiler. The compiler usually has a special option to produce PIC code, under
-fPICoption produces PIC code. Shared libraries have suffixes that are architecture dependent: under SunOS4.1 and Solaris, shared libraries end with
libg++.so); under HPUX, shared libraries end with
In addition, shared libraries can also have versioning information included in the name. Shared library versioning is architecture dependent, but a versioned shared library name might look like
libg++.so.2.7.1. Note that the version of a shared library can be encoded in the shared library in the
SONAMEfeature of that library. Usually, the
SONAMEof a library is the same as the filename (i.e., the
libg++.so.2.7.1). Interestingly, if you rename a shared library without changing the
SONAMEand then link against the renamed shared library, then at runtime the binary may report that it cannot find the proper library.
The constraint with shared libraries is that the binary be able to find the shared libraries at run time. Exactly how this is done is architecture dependent, but in general the runtime linker looks for special environment variable that contains pathnames for directories to be searched. Under SunOS4.1.x and Solaris2.x, this environment variable is named
LD_LIBRARY_PATH. Under HPUX, the variable is named
SHLIB_PATH. A binary can also have a list of pathnames to be searched encoded inside it. Usually this is called the
RPATH. In general, asking the user to set the
SHLIB_PATHis frowned upon. It is better if the binary has the proper
RPATHset at link time.
.ofiles archived together. A
.ofile inside a library might contain symbols (functions, variables etc.) that are not used by your program.
At link time, a static library can have unresolved symbols in it, as long as you don't need the unresolved symbols, and you don't need any symbol that is in a
.ofile that contains an unresolved symbol. However, with shared libraries, you must resolve all the symbols at link time, even if you don't necessarily use the unresolved symbol.
As an example, say you have a program that uses a symbol from the
$PTOLEMY/lib.$PTARCH/libpigi.*), but does not use Octtools which is used by other files that make up the
If you are linking with a static library, you can have some unresolved symbols in the static library, as long as you don't reference the unresolved symbols. So, in our example, you could just link with the static
If you are linking with a shared
libpigi, you must resolve all the unresolved symbols. So, if you need a symbol from the
libpigilibrary, then you must also include references to the Octtools libraries that pigilib uses, even though you are not using Octtools. So you would have to link in
libport.soand the other Octtools libraries.
One positive benefit of this is that all the symbols in pigilib are available at run time, which makes incremental linking much easier, especially if we have a shared g++ library.
stars.cfile (where xxx is the domain name, an example file is
$PTOLEMY/src/domains/sdf/stars/sdfstars.c) which gets compiled into xxx
stars.o. At link time, the xxx
stars.ofile is included in the link command and the linker searches
stars.afor the symbols defined in xxx
stars.o, and pulls in the rest of the star definition.
If you are using shared libraries, then all the symbols in the
starsfile are present at runtime, so you need not include the xxx
stars.ofile at link time.