The following lists the basic implementation of the static and dynamic linking mechanisms:
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.
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.