C compilation system


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

There are one or two cases in which you might not want to use dynamic linking. Because code in a dynamically linked library is not copied into your executable object file at link time, a dynamically linked executable normally uses less disk space than a statically linked executable. If your program calls only a few small library functions, however, the bookkeeping information to be used by the dynamic linker may take up more space in your executable than the code for those functions. You can use the size command to determine the difference. See size(CP) for more information.

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 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.

Next topic: Guidelines for building dynamically linked libraries
Previous topic: Dynamic linking programming interface

© 2003 Caldera International, Inc. All rights reserved.
SCO OpenServer Release 5.0.7 -- 11 February 2003