Filter
Top Products
Chapter 5 171
Creating and Using Libraries
Caution When Mixing Shared and Archive Libraries
Example 3: Hidden Definitions
This example shows how mixing archive libraries and shared libraries
can lead to multiple definitions in the application and unexpected
results. If one of the definitions happens to be a data symbol, the results
can be catastrophic. If any of the definitions are code symbols, different
versions of the same routine could end up being used in the application.
This could lead to incompatibilities.
Duplicate definitions can occur when a dependent shared library is
updated to refer to a symbol contained in the program file but not visible
to the shared library. The new symbol import must be satisfied somehow
by either adding the symbol to the library or by updating the shared
library dependency list. Otherwise the application must be relinked.
Using an archive version of libc in an application using shared libraries
is the most common cause of duplicate definitions. Remember that
symbols not referenced by a shared library at link time will not be
exported by default.
NOTE Duplicate definitions can be avoided if any or all symbols that may be
referenced by a shared library are exported from the application at link
time. Shared libraries always reference the first occurrence of a
definition. In the following example the first definition is in the
executable file, a.out. See the -E option and +e symbol option described
in ld(1) and “Exporting Symbols from main with -E” on page 81,
“Exporting Symbols with +ee” on page 81, and “Exporting Symbols with
+e” on page 79.
The following example illustrates this situation. Suppose you have a
main program, main(), and three functions, f1(), f2(), and f3() each
in a separate source file. main() calls f1(), f2(), and f3().
$ cc -c main.c Compile to relocatable code.
$ cc -c +z f1.c f2.c f3.c Compile to position-independent code.