OBJECT AND LIBRARY ORDERING
The ordering of object files, archive libraries, and shared libraries on
the command line affects how symbols are resolved. For example, if an
archive library appears before an object file or shared library that refer-
ences one of its symbols, the linker may report that symbol as unresolved.
Unresolved symbol errors can be avoided by adhering to the following
suggestions:
+ Object files should be ordered before all archive libraries and shared
libraries.
+ If archives and shared libraries cannot be specified in dependency
order, shared libraries should be ordered before archive libraries.
+ If necessary, archives can be specified more than once on the ld com-
mand line to handle unresolved symbols that were encountered after
previous symbol-resolution passes through the archives.
Symbols defined in object files are always included in the output object.
Ordering object files first might prevent the inclusion of conflicting sym-
bols that are also defined in archive libraries or shared libraries speci-
fied on the ld command line.
Both of the following two link OK:
ld -static -o hello hello.o foo.o /usr/lib/crt.o -Lgcc -print-file-name= -lc -lgcc
ld -static -o hello foo.o hello.o /usr/lib/crt.o -Lgcc -print-file-name= -lc -lgcc
As each object, archive library, and shared library is processed by the
linker, new symbol definitions and references are added to the output
object. If a symbol reference is added for a symbol that does not yet have
an associated symbol definition, it is an "undefined" symbol. The linker
must find a definition of every undefined symbol. The definition must exist
in either an object, archive, or shared library specified on the command
line. Archives and shared libraries are processed in the following ways:
+ When the linker processes an archive library, it extracts objects from
the archive that define any symbols that are currently undefined. As
each object is extracted from an archive library, the linker processes
the object, identifies any additional undefined symbols, and extracts
the objects that define those symbols.
The following links OK:
ld -static -o hello hello.o foo.o /usr/lib/crt.o -Lgcc -print-file-name= -lc -lgcc
libgcc.a:
ld -static -o hello hello.o foo.o /usr/lib/crt.o -Lgcc -print-file-name= -lgcc -lc
/usr/lib/libc.a(strtoll.o)(.text+0x104): In function __strtoll_internal':<br />: undefined reference toudivdi3’
/usr/lib/libc.a(strtoll.o)(.text+0x118): In function `strtoll_internal’:
: undefined reference to __umoddi3'<br />/usr/lib/libc.a(strtoull.o)(.text+0x104): In functionstrtoull_internal’:
: undefined reference to `udivdi3’
/usr/lib/libc.a(strtoull.o)(.text+0x118): In function __strtoull_internal':<br />: undefined reference to__umoddi3’
ar -q libfoo.a foo.o
ld -static -o hello hello.o /usr/lib/crt.o -L. -lfoo -Lgcc -print-file-name= -lc -lgcc
ld -static -o hello -lfoo hello.o /usr/lib/crt.o -L. -Lgcc -print-file-name= -lc -lgcc
hello.o(.text+0x21): In function main':<br />: undefined reference tofoo’
+ When the linker processes a shared library, it extracts symbol defini-
tions from the shared library for symbols that are currently unde-
fined. These symbol definitions are added to the output object. The
shared library might also define many symbols that are not added to
the output object. These symbols will not be considered as additional
objects (archive libraries and shared libraries) are processed; how-
ever, the linker does not report these symbols as unresolved if they
are referenced in objects ordered after the shared library on the com-
mand line. / by jfo: ie they are remembered by the linker, if referenced
later by object files(not archive libraries or shared libraries), add them;
if not, discard them when generating the final object. If it is the .a or .so
libraries referenced them, it will be undefined. /
gcc -shared -fpic foo.c -o libfoo.so
gcc -shared -fpic foo2.c -o libfoo2.so
ld –dynamic-linker /lib/ld-linux.so.2 -L. -Lgcc -print-file-name= -lfoo -lfoo2 -lc -lgcc_s -o hello hello.o /usr/lib/crt.o -lc
ld –dynamic-linker /lib/ld-linux.so.2 -L. -Lgcc -print-file-name= -lfoo2 -lfoo -lc -lgcc_s -o hello hello.o /usr/lib/crt.o -lc
why are they the same???
The later is expected to fail! But it passed.
The linker also identifies new undefined symbols while processing a
shared library. These undefined symbols are not added to the output
object and are not reported as unresolved, but the linker does con-
sider these undefined symbols as it processes additional objects on
the command line. / by jfo: ie when defined later, the linker will probably
resolved it. /
The following will link OK, / libc.so depends on libgcc_s.so ? /
ld –dynamic-linker /lib/ld-linux.so.2 -o hello hello.o foo.o /usr/lib/crt.o -Lgcc -print-file-name= -lc
/ld –dynamic-linker /lib/ld-linux.so.2 -o hello hello.o foo.o /usr/lib/crt.o -Lgcc -print-file-name= -lgcc_s -lc/
sample codes (Redhat9 gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5))