Implementation

The following lists the basic implementation of the static and dynamic linking mechanisms:

• When you use an archive library function, a copy of the object file that contains the function is incorporated in your executable at link time. External references to the function are assigned virtual addresses when the executable is created.

• When you use a function in a dynamically linked library, the entire contents of the library are mapped into the virtual address space of your process at run time. External references to the function are assigned virtual addresses when you execute the program. The link editor records in your executable only the filename of the dynamically linked library and a small amount of bookkeeping information for use by the dynamic linker at run time.

In a similar way, using a dynamically linked library may occasionally add to the memory requirements of a process. Although the text segment of a dynamically linked library is shared by all processes that use it, its writable data typically is not. See ``Guidelines for building dynamically linked libraries'' for details. Every process that uses a dynamically linked library usually gets a private copy of its entire data segment, regardless of how much of the data is needed. If an application uses only a small portion of text and data segments of a dynamically linked library, executing the application might require more memory with a dynamically linked library than without one. For example, it would waste memory to use the dynamically linked library version of standard C library to access only strcmp(). Although sharing strcmp() saves space on your disk and memory on the system, the memory cost to your process of having a private copy of the C library's data segment would make the archive version of strcmp() the more appropriate choice.

Now consider dynamic linking in more detail. First, each process that uses a dynamically linked library references a single copy of its code in memory. That means that when other users on your system call a function in a dynamically linked library, the entire contents of that library are mapped into the virtual address space of their processes as well. If they have called the same function as you, external references to the function in their programs will, in all likelihood, be assigned different virtual addresses. Because the function may be loaded at a different virtual address for each process that uses it, the system cannot calculate absolute addresses in memory until run time.

Secondly, the memory management scheme underlying dynamic linking shares memory among processes at the granularity of a page. Memory pages can be shared as long as they are not modified at run time. If a process writes to a shared page while relocating a reference to a dynamically linked library, it gets a private copy of that page and loses the benefits of code sharing without affecting other users of the page.

Thirdly, to create programs that require the least possible amount of page modification at run time, the compiler generates position-independent code under the -K PIC option. Whereas executable code normally must be tied to a fixed address in memory, position-independent code can be loaded anywhere in the address space of a process. Because the code is not tied to specific addresses, it will execute correctly -- without page modification -- at a different address in each process that uses it. As we have indicated, you should specify -K PIC when you create a dynamically linked library:

cc -dy -K PIC -G -o libfoo.so function1.c function2.c function3.c

Relocatable references in your object code are moved from its text segment to tables in the data segment. See ``ELF object files'' for details.