eld Manual

Binding of References
eld Manual—527255-009
3-5
Presetting Loadfiles
Presetting Loadfiles
This section discusses how the linker presets a loadfile. Except as mentioned
otherwise below, import libraries are used the same way that DLLs are, and remarks
made here about DLLs in the search list also apply to import libraries in the search list.
The search list begins with the loadfile itself. Next, for a program that has a user library,
comes the user library. The user library mostly acts the same as any other DLL, except
for its special placement at this point in the search list. After that come the entries in
this loadfile’s own .liblist section, namely, the DLLs that were obtained from the
command stream, in the order they were found in the command stream.
Then, each DLL that has already been placed into the search list after the loadfile itself
can specify other DLLs in its .liblist section. The linker finds these other DLLs by using
the names in the .liblist section. The linker performs a breadth-first traversal of all these
.liblist sections in order to add more entries to the search list. The names added to the
search list after the .liblist entries of the loadfile itself are called the indirect DLLs. A
DLL is only added to the search list if its DLL name is different from all of those already
in the search list. If the loadfile being built is localized then the traversal to find indirect
DLLs only pays attention to .liblist section entries that are re-exported. The linker
makes use of the DLL names found in one .liblist section in order to search for other
DLLs, but does not check that the DLL name found within a DLL matches the name
that was used to search for it.
The same kinds of rules that apply to DLLs found directly in the command stream, as
given in How the Linker Finds Its Input Files and Creates the .liblist Section on
page 2-12, also apply to indirect DLLs. This includes the following things:
•
The rule that, when the -make_implicit_lib option is used, all the DLLs that
are found must be implicit.
•
The rules about multiple DLLs with the same DLL name.
•
The rules about which informational messages to write out.
•
The rules about what to do if a search completes without finding a DLL.
The above rules about an indirect DLL are not enforced when the linker does not look
for that DLL. More specifically:
•
The linker does not look up a name found in a .liblist section entry if that entry is
not reexported and the linker is building a localized file.
•
The linker need not look up names in .liblist sections after it has decided that it is
neither going to preset nor check for unresolved references. (But the linker is
allowed to continue looking for DLLs in this case and do the usual checks on
them.)
Finally, if the -make_implicit_lib option has not been specified, the linker tries to
add the import library that represents the set of implicit libraries to the end of its search
list.