...
From the RTEMS shell
xxx
From C or C++ code
xxx
SO names, dependencies, namespaces and installation
Whether you call the linker from the shell or from your own code it obeys the same rules:
- The shared object whose name you give as an argument is never installed.
- If that shared object depends upon others then such of those others that are not already loaded are loaded.
- Shared objects that are loaded as dependencies are installed if they request it and if they are not already installed.
- A shared object isn't allowed to depend on itself.
...
An installed shared object is a sort of public library. It's loaded only once; if it's named as a dependency the already-loaded copy is re-useddynamic linker won't bother loading it again. The prototypical example is system:rtems.so which is needed by practically every other shared object. This way we don't have to load multiple copies of rtems.so.
...
Other shared objects besides system:rtems.so may be installed. In general, a shared object that the dynamic linker loads in order to satisfy a dependency it will also install if the shared object requests it. In such a case that single loaded copy is used whenever named as a dependency not only in that run of the linker but in all subsequent runs. In any given run of the linker it will load any object only once, but those objects that are not installed will be re-loaded if need be in subsequent runs, ignoring any copies loaded in previous runs. In this case shared objects are really unshared.
Resolving symbolic references
Though each shared object contains a list of the sonames of all the other shared objects it depends on, the so-called needed-list, this doesn't tell the dynamic linker just what the object requires from the other objects. It could be user data, functions, classes, etc. Each of these items has a symbolic name which appears in a symbol table built into the shared object that defines them. The object that needs to use them also has the symbolic names in its table, though marked as "undefined", that is to say "not defined in this shared object". There is no indication of which shared object is the definer. Instead, for each undefined symbol in a newly-loaded object the dynamic linker searches for a definition in each of the objects on the first object's needed-list, taking the first definition that it finds. It doesn't check for duplication. The linker then puts the address of the definition it found into all the places in the first shared object that require it.