What does ld do when linking against dynamic shared library?

Question

When linking an application against a dynamic shared library such as in

gcc -o myprog myprog.o -lmylib

I know the linker ( ld on my Linux) use the -l option to store in the produced myprog ELF executable file the name of the library ( mylib in this case) that will be used at load and link time (both when the program will be started if we ignore lazy dynamic linking). I am wondering what are the other jobs perform by ld (I am only speaking of the static linking step done at compilation time) regarding the dynamic shared library ?

• ld must checks for undefined symbol existence in provided dynamic shared libraries
• any other stuff ?

Moreover, I will be interested on pointers you are using (books, online documentation) regarding ELF format and dynamic linking and loading processes.

Answer 1

While you hit the most obvious things ld needs to do when linking to ELF shared libraries, there are a few more you missed. I'll re-state the ones you mentioned and add some more:

1. Ensuring that all undefined symbols are resolved (unless the output is a shared library itself, in which case undefined symbols are valid).

2. Storing a reference to the library in a DT_NEEDED record of the _DYNAMIC object of the output file.

3. If the output is not position-independent and references objects (in the sense of data, as opposed to functions) in the shared library, generating a copy relocation to copy the original image of the object into the main program's data segment at load time, and the proper symbol table entry so that references to the object in the shared library itself get resolved to the new copy in the main program, rather than the original copy in the library.

4. Generating PLT thunks for the destination of each function call in the output that's not resolved at ld -time to a definition in the output.

These are the tasks I can think of that are specific to use of shared libraries, and of course don't include all the work that the linker already does which would be the same as for static linking. One way to think of what ld does with dynamic linking is that it takes object files with a huge repertoire of relocation types (representing anything the compiler or assembler can produce) and resolves all but a small number of them (for static linking, that number would be zero), where all of the remaining relocations fit into a much more limited set of types resolvable by the dynamic linker at load time.

Answer 2

One important step is the creation of a dynamic symbol table , which the runtime linker ld.so can use to link the executable against the library at runtime. It will also write the dynamic relocation table to note which machine code locations need to be changed to point to dynamically linked symbols. To see details:

objdump -T myprog
objdump -R myprog

Also note that the string written to the executable will actually be the SONAME of the library, which might be something like mylib.so.0 . This will ensure that even when you install a newer and incompatible mylib.so.1.42 at some later point, the executable will use the compatible ABI version 0 instead. For details:

ldd myprog

Of course, the linker will also link your object files against one another, but since it does that even in the absence of a dynamic shared library, I take it that you are not interested in this part of its operation.