How does gnu linker work

In this case -fpic or -fPIC is preserved, but not enabled automatically. This allows to build shared libraries without position-independent code on architectures where this is possible, i. The sections containing intermediate code for link-time optimization are merged, pre-optimized, and output to the resulting object file. In addition, if -ffat-lto-objects is specified, binary code is produced for future non-LTO linking.

The object file produced by incremental linking is smaller than a static library produced from the same object files.

At link time the result of incremental linking also loads faster than a static library assuming that the majority of objects in the library are used. When multiple object files are linked together the resulting code is better optimized than with link-time optimizations disabled for example, cross-module inlining happens , but most of benefits of whole program optimizations are lost.

During the incremental link by -r the linker plugin defaults to rel. To maintain whole program optimization, it is recommended to link such objects into static library instead. Alternatively it is possible to use H. Search the library named library when linking. The second alternative with the library as a separate argument is only for POSIX compliance and is not recommended. The -l option is passed directly to the linker by GCC. Refer to your linker documentation for exact details.

The general description below applies to the GNU linker. The linker searches a standard list of directories for the library. The directories searched include several standard system directories plus any that you specify with -L. Static libraries are archives of object files, and have file names like lib library.

Some targets also support shared libraries, which typically have names like lib library. If both static and shared libraries are found, the linker gives preference to linking with the shared library unless the -static option is used.

It makes a difference where in the command you write this option; the linker searches and processes libraries and object files in the order they are specified. If bar. Do not use the standard system startup files when linking. The standard system libraries are used normally, unless -nostdlib , -nolibc , or -nodefaultlibs is used. Do not use the standard system libraries when linking.

Only the libraries you specify are passed to the linker, and options specifying linkage of the system libraries, such as -static-libgcc or -shared-libgcc , are ignored. The standard startup files are used normally, unless -nostartfiles is used. The compiler may generate calls to memcmp , memset , memcpy and memmove.

These entries are usually resolved by entries in libc. These entry points should be supplied through some other mechanism when this option is specified. Do not use the C library or system libraries tightly coupled with it when linking. This typically removes -lc from the link command line, as well as system libraries that normally go with it and become meaningless when absence of a C library is assumed, for example -lpthread or -lm in some configurations. This is intended for bare-board targets when there is indeed no C library available.

Do not use the standard system startup files or libraries when linking. Show 6 more comments. Actually, one could say linking is relatively simple. Richard J. Ross III Matthieu M. The term to search for wrt the first point is "name mangling" btw — Marco van de Voort. MarcovandeVoort: not really.

For example, there is no manging in C, and yet there is still a linker. Duplicate symbols are generally weak symbols, like functions marked inline , instances of template functions, instances of template static symbols etc Those get generated for every translation unit, but only one should be thrown into the final library and it is the linker job.

If you wanted to know what complicates the real linker, you could start here: airs. Matthieu It depends what you mean C does have mangling on some platforms notably Windoze. See Raymond Chen. MarcovandeVoort: It's relevant in forming the names of the symbols, but whether you mangle or not is independent from whether you have duplicate in different objects or not. Show 2 more comments. Employed Russian Employed Russian k 27 27 gold badges silver badges bronze badges.

Thanks for the blog link, really interesting serie indeed. Normally answers containing only links are frown upon though what if the blog suddenly shut downs? I've always thought this rule of SO is stupid, it's a waste of time to try and summarise an entire series of posts by a leading expert on linkers in a brief SO answer. The question is not suitable for SO precisely because the answer cannot be summarised in a few paragraphs and the right way for the OP to get the answer is to read detailed information elsewhere, not a summary here, and anyway what if SO shuts down?

Ian has been using airs. The Overflow Blog. Podcast Explaining the semiconductor shortage, and how it might end. Does ES6 make JavaScript frameworks obsolete? Featured on Meta. Compilers and assemblers generate relocatable obj files including shared obj files.

Linkers generate executable obj files. Technically, an obj module is a sequence of bytes, and an obj file is an obj module stored on disk in a file. Each relocatable obj module, m , has a symbol table that contains info about the symbols that are defined and referenced by m. In the context of a linker, there are three different kinds of symbols:.

Symbol tables are built by assemblers , using symbols exported by the compiler into the assembly-language. An ELF symbol table is contained in the. It contains an array of entries. Each symbol is associated with some section of the obj file, denoted by the section field, which is an index into the section header table. There are three special pseudo sections that don't have entries in the section header table:. The first nine entries in the symbol table are local symbols that the linker uses internally, and we care more about the remaining ones:.

The linker resolves symbol references by associating each ref with exactly one symbol definition from the symbol tables of its input relocatable obj files.

Symbol resolution is easy for references to local variables that are defined in the same module as the ref. Resolving ref to global symbols is trickier. When the compiler encounters a symbol either a var or func name that is not defined in the current module, it assumes that it is defined in some other module, generally a linker symbol table entry , and leaves it for the linker to handle.

If the linker is unable to find a def for the referenced symbol in any of its input modules, it prints an error msg and terminates. Related funcs can be compiled into separate obj modules and then packaged in a single static library file. Application programs can then use any of the funcs defined in the library by specifying a single file name on the command line:.

At link time, the linker will only copy obj modules that are referenced by the program, which reduces the size of the executable on disk and in memory. On Unix systems, static libraries are stored on disk as archive , which is a collection of concatentated relocatable obj files, with a header that describes the size and loc of each member obj file.

During the symbol resolution phase, the linker scans the relocatable obj files and archives left to right in the same sequential order that they appear on the compiler driver's command line. The driver automatically translates any.

During this scan, the linker maintains a set E of relocatable obj files that will be merged to form the executable, a set U of unresolved symbols i. The ordering of libraries and obj files on the cmd line is significant, and the general rule is to place libraries at the end of cmd line. And, if libraries are not independent, they must be ordered so that for symbol s that is referenced externally by a member of an archive, at least one def of s follows a ref to s on the cmd line.

Then, libx. Libraries can be repeated on the cmd line if necessary to satisfy the dependence requirements. Then libx. Once the linker has completed the symbol resolution step, it has associated each symbol ref in the code with exactly one symbol def i. At this point, the linker knows the exact sizes of the code and data sections in its input obj modules. It is now ready to begin the relocation step, where it merges the input modules and assigns run-time addr to each symbol.

Relocation consists of two steps:. When an assembler generates an obj module, it does not know where the code and data will ultimately be stored in memory. Nor does it know the locs of any externally defined funcs or global vars that are referenced by the module. So, whenever the assembler encounters a ref to an obj whose ultimate loc is unknown, it generates a relocation entry that tells the linker how to modify the ref when it merges the obj file into an executable.

Relocation entries for code are placed in. These fields tell the linker to modify the bit PC-relative ref starting at offset 0x7 so that it will point to the swap routine at run time.

Now suppose the linker has determined that.