Overview
xxx
Using the dynamic linker
xxx
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.
Each shared object has a name, the so-called SO name or soname, used as follows:
- Each shared object has its own soname built into it.
- Each shared object refers to the other shared objects that it depends on by their sonames.
- The system tracks installed shared objects by their sonames.
An installed shared object is a sort of public library. It's loaded only once; if it's named as a dependency the dynamic 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.
Notice that the soname "system:rtems.so" has two components separated by a colon. The first component, "system" give the namespace to which the shared object belongs. Objects wiin the same namespace are found in the same place. Where that place is is determined by the system's namespace table; each namespace name is associated with a directory in the RTEMS filesystem. The second component, "rtems.so" is the filename of the shared object after all directories have been removed. If the system namespace table associates "/mnt/rtems" with the namespace "system" then "system:rtems.so" will be looked for at /mnt/rtems/rtems.so when the time comes to load it.
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.