Static Mode

This mode is selected when the -dn option is used, and allows for the creation of relocatable objects and static executables. Under this mode only relocatable objects and archive libraries are acceptable forms of input. Use of the -l option will result in a search for archive libraries.

Building a Relocatable Object

• Use the -dn and -r options:

$ cc -dn -r -o temp.o file1.o file2.o file3.o .....

Building a Static Executable

• Use the -dn option without the -r option:

$ cc -dn -o prog file1.o file2.o file3.o .....

---

Note - The -a option is available to indicate the creation of a static executable, however, the use of -dn without a -r implies -a.

---

Dynamic Mode

This is the default mode of operation for the link-editor. It can be enforced by specifying the -dy option, but is implied when not using the -dn option. Under this mode relocatable objects, shared objects and archive libraries are acceptable forms of input. Use of the -l option will result in a directory search, where each directory is searched for a shared object, and if none is found the same directory is then searched for an archive library. A search for archive libraries only, can be enforced by using the -B static option (refer to "Linking with a Mix of Shared Objects and Archives" on page 15).

Building a Shared Object

• Use the -dy and -G option.
• Input relocatable objects should be built from position-independent code, and use the -z text option to enforce this requirement (refer to "Position-Independent Code" on page 85).
• Use a versioned name for the shared object to allow for future upgrades (refer to "Versioning" on page 73).

• If the shared object being generated has dependencies on any other shared objects, and these dependencies do not reside in /usr/lib, record their pathname in the output file using the -R option (refer to "Shared Objects With Dependencies" on page 76).

The following example combines the above points:

$ cc -c -o foo.o -Kpic foo.c $ cc -dy -G -o libfoo.so.1 -z text -R /home/lib foo.o -L. -lbar

• If the shared object being generated will be used as input to another link-edit, record within it the shared object's runtime name using the -h option (refer to "Recording a Shared Object Name" on page 69). Make the shared object available to the compilation environment by creating a file system link to a non-versioned shared object name (refer to "Coordination Of Binding Requirements" on page 74):

$ cc -dy -G -o libfoo.so.1 -z text -h libfoo.so.1 foo.o $ ln -s libfoo.so.1 libfoo.so

• Consider the performance implications of the shared object; maximize shareability (refer to page 86) and minimize paging activity (refer to page 89), reduce relocation overhead, especially by minimizing symbolic relocations (refer to "Relocations" on page 90), and allow access to data via functional interfaces (refer to "Copy Relocations" on page 91).

Building a Dynamic Executable

• Use the -dy option without the -G option.
• If the dynamic executable being generated has dependencies on any other shared objects, and these dependencies do not reside in /usr/lib, record their pathname in the output file using the -R option (refer to "Directories Searched by the Runtime Linker" on page 18).

The following example combines the above points:

$ cc -dy -o prog -R /home/lib -L. -lfoo