In article <PLO.95Oct2090
...@heidi.came.sbg.ac.at>,
Peter Lackner <p
...@olga.came.sbg.ac.at> wrote:
:I'm running IRIX5.2. I have problems when linking static libraries. The
:result depends stronly on the order of the libraries on the linker line.
:If I do not have the right order I get 'unresolved externals'.
:
:Example: I have 4 libs: A,B,C,D
:cc -o prog -lA -lB -lC -lD does not work
:cc -o prog -lC -lA -lB -lD works
:Can I do something to solve this "dependency problem" ?
:What is the reason that this happens ?
This is normal and expected.
The linking process starts at the left and moves towards the right.
The linker will only search a library for symbols which are currently
undefined. It will link whatever portions of the library it needs,
and will remove from the list any symbols it was able to resolve,
and add to the list any new symbols referred to by the library that
the library does not already define. It then moves to the next library
on the right and does the same process over again. It does NOT keep
a list around of all symbols it has seen in previous libraries, and
does NOT do additional passes through the libraries if some items are
still undefined.
Example:
Suppose the program refers to 'a' and 'b' but does not define them.
Suppose the first library on the link line, 'B' defines 'b' and 'c',
and the second library on the link line, 'A' defines 'a' and 'a' refers to 'c'.
The linker starts with the program. It now has 'a' and 'b' undefined.
It proceeds to the first library. 'B' defines 'b', so 'b' gets bound in and
removed from the list. There is no active unresolved reference to 'c', so
that is ignored. 'B' did not add additional unresolved symbols, so nothing
gets added to the list. 'a' is now the only unresolved item. The linker
proceeds to library 'A'. 'A' defines 'a', so that gets bound in and
removed from the list. 'a' needs 'c', which is not defined in 'A', so 'c'
gets added to the list. The linker proceeds, finding the end of the library
line. 'c' is on the list and there are no more libraries, so 'c' is declared
as unresolved.
Exchange now the order of the libraries on the link line. The linker
starts with the program, 'a' and 'b' are unresolved so it adds them to the
list. It proceeds to library 'A'. 'A' defines 'a' so 'a' gets bound in and
removed from the list. 'a' needs 'c' which is not defined in 'A', so 'c'
gets added to the list. The list now contains 'b' and 'c'. The linker
proceeds to the next library on the list, 'B'. 'B' defines 'b', so 'b'
gets bound in and removed from the list. 'B' also defines 'c' so 'c' gets
bound in and removed from the list. The list is now empty. The linker
proceeds, finding the end of the library line. The list is empty, so
there are no unresolved symbols, and everything is well.
Suppose now that 'A' defines 'a' and 'c' and 'a' refers to 'b', and
that 'B' defines 'b' and 'b' refers to 'c'. In this situation, all that
one can do is list one library *twice* on the command line: either
-lA -lB -lA or -lB -lA -lB would do for this example. If 'A' is first,
the definition of 'c' is ignored the first time, as 'c' is not a symbol
that needs to be resolved at that point. If 'B' is first, the definition
of 'b' is not available when 'a' of 'A' needs it. It is best to avoid all such
situations!!
Walter Roberson rober...@ibd.nrc.ca
