ELF object files

Dynamic linker

When building an executable file that uses dynamic linking, the link editor adds a program header element of type PT_INTERP to an executable file, telling the system to invoke the dynamic linker as the program interpreter. exec() and the dynamic linker cooperate to create the process image for the program, which entails the following actions:

NOTE: The location(s) of the system provided dynamic linker(s) are processor specific.

Adding the executable file's memory segments to the process image;
Adding shared object memory segments to the process image;
Performing relocations for the executable file and its shared objects;
Closing the file descriptor that was used to read the executable file, if one was given to the dynamic linker;
Transferring control to the program, making it look as if the program had received control directly from exec().

The link editor also constructs various data that assist the dynamic linker for executable and shared object files. As shown previously in ``Program header'', this data resides in loadable segments, making them available during execution.

A .dynamic section with type SHT_DYNAMIC holds various data. The structure residing at the beginning of the section holds the addresses of other dynamic linking information.
The .hash section with type SHT_HASH holds a symbol hash table.
The .got and .plt sections with type SHT_PROGBITS hold two separate tables: the global offset table and the procedure linkage table. Sections below explain how the dynamic linker uses and changes the tables to create memory images for object files.

As explained in ``Program loading (processor-specific)'', shared objects may occupy virtual memory addresses that are different from the addresses recorded in the file's program header table. The dynamic linker relocates the memory image, updating absolute addresses before the application gains control. Although the absolute address values would be correct if the library were loaded at the addresses specified in the program header table, this normally is not the case.

If the process environment contains a variable named with a non-null value the dynamic linker processes all relocations before transferring control to the program.

NOTE: See ``Checking for run-time compatibility'' for more information.

For example, all the following environment entries would specify this behavior.

LD_BIND_NOW=1
LD_BIND_NOW=on
LD_BIND_NOW=off

Otherwise, LD_BIND_NOW either does not occur in the environment or has a null value. The dynamic linker is permitted to evaluate procedure linkage table entries slowly, thus avoiding symbol resolution and relocation overhead for functions that are not called.