5.3: Linker

The linker(For more information, refer to: http://en.Wikipedia.org/wiki/Linker_(computing)), sometimes referred to as linkage editor, will combine one or more object files into a single executable file. Additionally, any routines from user or system libraries are included as necessary. The GNU gold linker, ld(For more information, refer to: http://en.Wikipedia.org/wiki/Gold_(linker)), is used. The appropriate linker command for the example program from the previous chapter is as follows:

     ld -g -o example example.o

Note, the -o is a dash lower-case letter O, which can be confused with the number 0.

The -g option is used to inform the linker to include debugging information in the final executable file. This increases the size of the executable file, but is necessary to allow effective debugging. The -o example specifies to create the executable file named example (with no extension). If the -o <fileName> option is omitted, the output file is named a.out (by default). The example.o is the name of the input object file read by the linker. It should be noted that the executable file could be named anything and does not need to have the same name as any of the input object files.

Linking Multiple Files

In programming, large problems are typically solved by breaking them into smaller problems. The smaller problems can be addressed individually, possibly by different programmers.

Additional input object files, if any, would be listed, in order, separated with a space. For example, if there are two object files, main.o and funcs.o the link command to create an executable file name example, with debugging information included, would be as follows:

     ld -g -o example main.o funcs.o

This would typically be required for larger or more complex programs.

When using functions located in a different, external source file, any function or functions not in the current source file must be declared as extern. Variables, such as global variables, in other source files can be accessed by using the extern statement as well, however data is typically transferred as arguments of the function call.

Linking Process

Linking is the fundamental process of combining the smaller solutions into a single executable unit. If any user or system library routines are used, the linker will include the appropriate routines. The object files and library routines are combined into a single executable module. The machine language code is copied from each object file into a single executable.

As part of combining the object files, the linker must adjust the relocatable addresses as necessary. Assuming there are two source files, the main and a secondary source file containing some functions, both of which have been assembled into object files main.o and funcs.o. When each file is assembled, the calls to routines outside the file being assembled are declared with the external assembler directive. The code is not available for an external reference and such references are marked as external in the object file. The list file will show an R for such relocatable addresses. The linker must satisfy the external references. Additionally, the final location of the external references must be placed in the code.

For example, if the main.o object file calls a function in the funcs.o file, the linker must update the call with the appropriate address as shown in the following illustration.

Here, the function fnc1 is external to the main.o object file and is marked with an R. The actual function fnc1 is in the funcs.o file, which starts its relative addressing from 0x0 (in the text section) since it does not know about the main code. When the object files are combined, the original relative address of fnc1 (shown as 0x0100:) is changed to its final address in executable file (shown as 0x0400:). The linker must insert this final address into the call statement in the main (shown as call 0x0400:) in order to complete the linking process and ensure the function call will work correctly.

This will occur with all relocatable addresses for both code and data.

Dynamic Linking

The Linux operating system supports dynamic linking(For more information, refer to: http://en.Wikipedia.org/wiki/Dynamic_linker), which allows for postponing the resolution of some symbols until a program is being executed. The actual instructions are not placed in executable file and instead, if needed, resolved and accessed at run-time.

While more complex, this approach offers two advantages:

• Often-used libraries (e.g., the standard system libraries) can be stored in only one location, not duplicated in every single binary.
• If a bug in a library function is corrected, all programs using it dynamically will benefit from the correction (at the next execution). Otherwise, programs that utilize this function by static linking would have to be re-linked before the correction is applied.

There are also disadvantages:

• An incompatible updated library will break executable’s that depended on the behavior of the previous version of the library.
• A program, together with the libraries it uses, might be certified (e.g. as to correctness, documentation requirements, or performance) as a package, but not if components can be replaced.

In Linux/Unix, the dynamically linked object files typically a have .so (shared object) extension. In Windows, they have a .dll (dynamically linked library) extension. Further details of dynamic linking are outside the scope of this text.