How the linker resolves references
When the linker has constructed the list of libraries, it repeatedly scans each library in the list to resolve references.
armlink maintains two separate lists of files. The lists are scanned in the following order to resolve all dependencies:
List of system libraries found in
../lib, or the directories specified by
--libpath. These might also be specified by the
The list of all other files that have been loaded. These might be specified by the
Each list is scanned using the following process:
Search all specified directories to select the most compatible library variants.
Add the variants to the list of libraries.
Scan each of the libraries to load the required members:
For each currently unsatisfied non-weak reference, search sequentially through the list of libraries for a matching definition. The first definition found is marked for processing in step 3.b.
The sequential nature of the search ensures that the linker chooses the library that appears earlier in the list if two or more libraries define the same symbol. This enables you to override function definitions from other libraries, for example, the ARM® C libraries, by adding your libraries to the input file list. However you must be careful to consistently override all the symbols in a library member. If you do not, you risk the objects from both libraries being loaded when there is a reference to an overridden symbol and a reference to a symbol that was not overridden. This results in a multiple symbol definition error
L6200Efor each overridden symbol.
Load the library members marked in step 3.a. As each member is loaded it might satisfy some unresolved references, possibly including weak ones. Loading a library member might also create new unresolved weak and non-weak references.
Repeat these stages until all non-weak references are either resolved or cannot be resolved by any library.
If any non-weak reference remains unsatisfied at the end of the scanning operation, generate an error message.