LINK Uses Library Sequence to Resolve External References (57706)
The information in this article applies to:
- Microsoft LINK for MS-DOS 2.x
- Microsoft LINK for MS-DOS 3.x
- Microsoft LINK for MS-DOS 4.x
- Microsoft LINK for MS-DOS 5.0x
- Microsoft LINK for MS-DOS 5.1x
- Microsoft LINK for MS-DOS 5.2x
- Microsoft LINK for MS-DOS 5.3x
- Microsoft LINK for MS-DOS 5.5
- Microsoft LINK for MS-DOS 5.6
- Microsoft LINK for OS/2 5.0x
- Microsoft LINK for OS/2 5.1
- Microsoft LINK for OS/2 5.11
- Microsoft LINK for OS/2 5.13
- Microsoft LINK for OS/2 5.15
This article was previously published under Q57706 SUMMARY
The "MS-DOS Encyclopedia" (Microsoft Press) includes the following
statement on pages 407 and 408:
When a public symbol required to resolve an external reference is
declared more than once among the object modules in the input
libraries, LINK uses the first object module that contains the
public symbol. This means that the actual executable code or data
associated with a particular external reference can be varied by
changing the order in which LINK processes its input libraries...
Each individual library is searched repeatedly (from first library
to last, in the sequence in which they are input to LINK) until no
further external references can be resolved.
The text below provides additional information about this process.
MORE INFORMATION
As an example, consider the application illustrated by the diagram
below:
Module MAIN Library A Library B1 Library C Library B2
+---------+ +----------+ +----------+ +----------+ +----------+
| calls A | | contains | | contains | | contains | | contains |
+---------+ | A, | | B | | C, | | B |
| calls C | +----------+ | calls B | +----------+
+----------+ +----------+
Microsoft LINK determines which copy of Module B the application uses
depending on the sequence in which the user specifies the libraries on
the linker command line. For example, calling the linker with the
following command line selects Module B from Library B2:
The linker searches Library C first. If it cannot resolve the
reference, it continues on to search Library B2. If it still cannot
resolve the reference, it returns only then to search Library A and
Library B1 to finally resolve the reference.
For a slightly more complex situation, consider the case in which
Library contains Module A and Module B, as the diagram below
illustrates:
Module MAIN Library A (remove B1) Library C Library B2
+---------+ +----------+ +----------+ +----------+
| calls A | | contains | | contains | | contains |
+---------+ | A, | | C, | | B |
| calls C | | calls B | +----------+
+----------+ +----------+
| contains |
| B |
+----------+
With the following command line, the linker selects Module B from
Library A:
Even though the linker always resolves module names using the same
rules, as the cases become more complex, it becomes increasingly
difficult to determine which version of a module the linker selects.
Where feasible, you can avoid this problem by placing the appropriate
version of a module into an OBJ file instead of a library. The linker
resolves references in OBJ files before it resolves references in
libraries.
For more information, please refer to article 20 in the "MS-DOS
Encyclopedia," "The Microsoft Object Linker" in the "Object Module Order"
section, pages 703-706. Note, however, that this book is currently out of
print.
Modification Type: | Major | Last Reviewed: | 10/23/2003 |
---|
Keywords: | kb16bitonly KB57706 |
---|
|