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:
The list of user files and libraries that have been loaded.
List of Arm® standard libraries found in a directory relative to the armlink executable, or the directories specified by
Each list is scanned using the following process:
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 1.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 1.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.