Prayer

https://www.ibm.com/support/knowledgecenter/ssw_aix_71/com.ibm.aix.genprogc/shared_object_runtime_linking.htm

By default, programs are linked so that a reference to a symbol imported from a shared object is bound to that definition at load time.

This is true even if the program, or another shared object required by the program, defines the same symbol.

run time linker

A shared object that allows symbols to be rebound for appropriately linked programs

You include the run time linker in a program by linking the program with the -brtl option. This option has the following effects:

• A reference to the run time linker is added to your program. When program execution begins, the startup code (/lib/crt0.o) will call the run time linker before the main function is called.
• All input files that are shared objects are listed as dependents of your program in your program's loader section. The shared objects are listed in the same order as they were specified on the command line. This causes the system loader to loadall these shared objects so that the run time linker can use their definitions. If the -brtloption is not used, a shared object that is not referenced by the program is not listed, even if it provides definitions that might be needed by another shared object used by the program.
• A shared object contained in an archive is only listed if the archive specifies automatic loading for the shared object member. You specify automatic loading for an archive member foo.o by creating a file with the following lines:

  # autoload #! (foo.o)

  and adding the file as a member to the archive.
• In dynamic mode, input files specified with the -l flag may end in .so, as well as in .a. That is, a reference to -lfoois satisfied by the first libfoo.so or libfoo.a found in any of the directories being searched. Dynamic mode is in effect by default unless the -bstatic option is used.

The run time linker mimics the behavior of the ld command when static linking is used, except that only exported symbols can be used to resolve symbols. Even when run time linking is used, the system loader must be able to load and resolve all symbol references in the main program and any module it depends on. Therefore, if a definition is removed from a module, and the main program has a reference to this definition, the program will not execute, even if another definition for the symbol exists in another module.

The run time linker can rebind all references to symbols imported from another module. A reference to a symbol defined in the same module as the reference can only be rebound if the module was built with run time linking enabled for that symbol.

Shared modules shipped with AIX® 4.2 or later have run time linking enabled for most exported variables. run time linking for functions is only enabled for functions called through a function pointer. For example, as shipped, calls to the malloc subroutine within shared object shr.o in /lib/libc.a cannot be rebound, even if a definition of malloc exists in the main program or another shared module. You can link most shipped shared modules to enable run time linking for functions as well as variables by running the rtl_enable command.

Operation of the run time linker

The main program is loaded and resolved by the system loader in the usual way. If the executable program cannot be loaded for any reason, the exec() subroutine fails and the run time linker is not invoked at all. If the main program loads successfully, control passes to the run time linker, which rebinds symbols as described below. When the run time linker completes, initialization routines are called, if appropriate, and then the main function is called.

The run time linker processes modules in breadth-first search order, starting with the main executable and continuing with the direct dependents of the main executable, according to the order of dependent modules listed in each module's loader section. This order is also used when searching for the defining instance of a symbol. The "defining instance" of a symbol is usually the first instance of a symbol, but there are two exceptions. If the first instance of a symbol is an unresolved, deferred import, no defining instance exists. If the first instance is a BSS symbol (that is, with type XTY_CM, indicating an uninitialized variable), and there is another instance of the symbol that is neither a BSS symbol nor an unresolved, deferred import, the first such instance of the symbol is the defining instance.

The loader section of each module lists imported symbols, which are usually defined in another specified module, and exported symbols, which are usually defined in the module itself. A symbol that is imported and exported is called a "passed-through'' import. Such a symbol appears to be defined in one module, although it is actually defined in another module.

Symbols can also be marked as "deferred imports." References to deferred import symbols are never rebound by the run time linker. Resolution of these symbols must be performed by the system loader, either by calling loadbind() or by loading a new module explicitly with load() or dlopen().

References to imported symbols (other than deferred imports) can always be rebound. The system loader will have already resolved most imports. References to each imported symbol are rebound to the symbol's defining instance. If no defining instance exists, an error message will be printed to standard error. In addition, if the typechecking hash string of an imported symbol does not match the hash string of the defining symbol, an error message is printed.

References to exported symbols are also rebound to their defining instances, as long as the references appear in the relocation table of the loader section. (Passed-through imports are processed along with other imports, as described above.) Depending on how the module was linked, some references to exported symbols are bound at link time and cannot be rebound. Since exported symbols are defined in the exporting module, a defining instance of the symbol will always exist, unless the first instance is a deferred import, so errors are unlikely, but still possible, when rebinding exported symbols. As with imports, errors are printed if the typechecking hash strings do not match when a symbol is rebound.

Whenever a symbol is rebound, a dependency is added from the module using the symbol to the module defining the symbol. This dependency prevents modules from being removed from the address space prematurely. This is important when a module loaded by the dlopen subroutine defines a symbol that is still being used when an attempt is made to unload the module with the dlclose subroutine.

The loader section symbol table does not contain any information about the alignment or length of symbols. Thus, no errors are detected when symbols are rebound to instances that are too short or improperly aligned. Execution errors may occur in this case.

Once all modules have been processed, the run time linker calls the exit subroutine if any run time linking errors occurred, passing an exit code of 144 (0x90). Otherwise, execution continues by calling initialization routines ormain().

Creating a shared object with run time linking enabled

To create a shared object enabled for run time linking, you link with the -G flag. When this flag is used, the following actions take place:

1. Exported symbols are given the nosymbolic attribute, so that all references to the symbols can be rebound by the run time linker.
2. Undefined symbols are permitted (see the -berok option). Such symbols are marked as being imported from the symbolic module name "..". Symbols imported from ".." must be resolved by the run time linker before they can be used because the system loader will not resolve these symbols.
3. The output file is given a module type of SRE, as if the -bM:SRE option had been specified.
4. All shared objects listed on the command line are listed as dependents of the output module, in the same manner as described when linking a program with the -brtl option.
5. Shared objects in archives are listed if they have the autoload attribute.

Using the -berok option, implied by the -G flag, can mask errors that could be detected at link time. If you intend to define all referenced symbols when linking a module, you should use the -bernotok option after the -G flag. This causes errors to be reported for undefined symbols.