The shared object does not contain symbols that should be there. Symbols that are neither exported nor referenced by content in the shared object are discarded by the ILINK linker.

To solve this, you can force their inclusion by exporting them, keeping them, or using the #pragma required directive. Note that the shared object can contain symbols that are not exported. To see which symbols that are imported or exported, you can use ielfdumparm to produce a listing of the contents (dump) of the section .dynsym (which is accessed by the dynamic linker). To see all symbols in the shared object, dump the section .symtab (which is not transferred to the target).

See ‑‑so_export, so_export directive, ‑‑keep, keep directive, required, and The IAR ELF Dumper—ielfdump.

Error Li066 is produced, with a list of symbols that are undefined in the shared object.

By default, the linker generates this error if the shared object contains references to symbols that are not defined in the shared object. Use the ‑‑so_import option or the so_import linker directive to allow the specified symbols—those symbols will be declared as external in the shared object. You can also allow all undefined symbols by specifying so_import *; (note the * wildcard).

Another option is to use the ‑‑diag_suppress or ‑‑diag_warning option to suppress the error or reduce it to a warning.

See ‑‑so_import and so_import directive.

Error Li067 is produced, with a list of symbols that are both defined in the shared object and declared as imported.

The shared object cannot both import and define the same symbol. A definition might be included by mistake, or you might be using an so_import directive that is not up to date.

Warning Li069 is produced, naming a symbol that is exported with its visibility set to hidden. The issue is that the code was generated under the assumption that it would not be called from outside the shared object. When a hidden symbol is exported, the function can be called by “anyone”.

This is not necessarily a problem, but a warning is produced to alert you that this is potentially unsafe. You must either suppress the warning with the ‑‑diag_suppress option or change the visibility of symbol to interposable or protected and recompile the code.

See ‑‑visibility.

There are local symbols in the .dynsym section, and the dynamic linker ignores them, or issues a diagnostic message for them.

The linker will output non-exported symbols as local symbols in the .dynsym section. Some dynamic linkers cannot handle this. You must export the symbols to get them to work. Export these symbols with the ‑‑so_export option or the so_export directive, or export all included public symbols by specifying so_export *; (note the * wildcard).

See ‑‑so_export and so_export directive.