Filter
Top Products
158 Chapter 5
Creating and Using Libraries
Switching from Archive to Shared Libraries
Switching from Archive to Shared
Libraries
There are cases where a program may behave differently when linked
with shared libraries than when linked with archive libraries. These are
the result of subtle differences in the algorithms the linker uses to
resolve symbols and combine object modules. This section covers these
considerations. (See also “Caution When Mixing Shared and Archive
Libraries”.)
Library Path Names
As discussed previously, in 32-bit mode, ld records the absolute path
names of any shared libraries searched at link time in the a.out file.
When the program begins execution, the dynamic loader attaches any
shared libraries that were specified at link time. Therefore, you must
ensure that any libraries specified at link time are also present in the
same location at run time.
For 64-bit naming, see “Internal Name Processing” for more information.
Relying on Undocumented Linker Behavior
Occasionally, programmers may take advantage of linker behavior that
is undocumented but has traditionally worked. With shared libraries,
such programming practices might not work or may produce different
results. If the old behavior is absolutely necessary, linking with archive
libraries only (-a archive) produces the old behavior.
For example, suppose several definitions and references of a symbol exist
in different object and archive library files. By specifying the files in a
particular link order, you could cause the linker to use one definition over
another. But doing so requires an understanding of the subtle (and
undocumented) symbol resolution rules used by the linker, and these
rules are slightly different for shared libraries. So make files or shell
scripts that took advantage of such linker behavior prior to the support
of shared libraries may not work as expected with shared libraries.