eld Manual

Binding of References
eld Manual—527255-009
3-8
Handling Unresolved References
the implicit libraries, if the linker found that library. If there was a DLL with the same
filename as the user library, then that DLL gets no LIC entry.
Note that, for each entry in the .lic, there is a bit that tells whether any references were
actually resolved by symbols exported from that DLL. The linker does not put out any
warning messages about DLLs that were “not used”. It is actually quite difficult to
decide which DLLs are “used”, because DLL A may indirectly bring in DLL B whose
symbols are used, even if that wasn’t true of DLL A. And, even that doesn’t mean that
DLL A was really “needed”, because there could also be other DLLs that similarly
cause DLL B to get brought into the link. (For ideas on related linker features, see
Ignoring Optional Libraries on page 3-14.)
The linker makes the .lic section larger than necessary so that it may be possible for
the object file to be modified by the -alf option when the LIC has to increase in size.
Even when the linker is not presetting it still creates the .lic section in a loadfile. The
section has no contents in this case, but it provides space for a subsequent -alf
option to create a LIC.
The -must_preset option tells the linker that it must be able to preset, or else it is to
be considered an error. eld reports an error if you give -must_preset with
-no_preset. Otherwise, if the linker can’t preset, and the -no_preset option was
not used, the linker generates a warning message.
Handling Unresolved References
This section discusses what the linker does when it is trying to bind a reference to a
symbol and that symbol is not found in any loadfile in the linker’s search list.
If an undefined symbol is mentioned only in the symbol table, with no references to it
from relocation tables, the linker continues processing. Checking for unresolved
references is only concerned with symbols that have references from code or data.
The treatment of an unresolved reference depends on whether the target symbol was
expected to be code or data. The linker knows this based on the symbol type listed for
the symbol in the ELF symbol table in the linkfile that refers to it. STT_OBJECT means
that it is data, and STT_FUNC means that it is code. No other possibilities are allowed.
The -unres_symbols option tells the linker how to treat unresolved references. It
takes a parameter value that is one of the following:
•
error - treat unresolved references as errors
•
warn - put out warning messages about unresolved references
•
ignore - be silent about unresolved references
-error_unresolved is supported as a synonym for -unres_symbols error,
and -warning_unresolved as a synonym for -unres_symbols warn.
When eld is building a new loadfile and a public DLL registry has not been found the
default for the -unres_symbols option is warn. On the other hand, if a public DLL