31 Dec
2018
31 Dec
'18
11:51 p.m.
On 12/30/18, Donald ODona <mutiny.mutiny(a)india.com> wrote:
At 30 Dec 2018 18:35:22 +0000 (+00:00) from Paul Winalski
<paul.winalski(a)gmail.com>:
No, you still need multiple inclusion in that situation. Consider
this situation:
main.o has an undefined reference to s1
m1.o in lib1.a defines s1 and has an undefined reference to s2
m3.o in lib1.a defines s3
m2.o in lib2.a defines s2 and has an undefined reference to s3
The command line is: ld main.o lib1.a lib2.a
The linker makes one or more passes over the index of lib1.a until no
more symbols are resolved. The linker loads m1.o. It does not load
m3.o because m3.o doesn't resolve any outstanding undefined
references.
The linker still has s2 undefined. It now makes one or more passes
over the index of lib2.a until no more symbols are resolved. In the
process it loads m2.o to resolve s2 and adds s3 to the list of
unresolved symbols.
After lib2.a is processed, s3 is still undefined, and ld has nothing
left to process. ld will issue an "unresolved symbol" error message
for s3. You need to specify lib1.a a second time to cause ld to scan
it again.
-Paul W.
Sometimes one runs into a situation where a module loaded from lib1.a
has an undefined symbol that causes a module from lib2.a to be loaded,
and that module in turn has an undefined symbol that is defined in
lib1.a. In that case, you have to cause the linker to scan lib1.a
twice:
ld main.o lib1.a lib2.a lib1.a
thats not true, because the M$ and borland linkers of the 80ths under
MSDOS(sic!) already processed indexed libraries. Therefore the multiple
inclusion of libraries wans'nt needed.