The following sections provide a simple overview, or cheat sheet, of the most commonly used link-editor scenarios (see "Link-Editing" for an introduction to the kinds of output modules generated by the link-editor).
The examples provided show the link-editor options as supplied to the compiler driver cc(1), this being the most common mechanism of invoking the link-editor (see "Using a Compiler Driver").
The link-editor places no meaning on the name of any input file. Each file is opened and inspected to determine the type of processing it requires (see "Input File Processing").
Shared objects that follow a naming convention of libx.so, and archive libraries that follow a naming convention of libx.a, can be input using the -l option (see "Library Naming Conventions"). This provides additional flexibility in allowing search paths to be specified using the -L option (see "Directories Searched by the Link-Editor").
The link-editor basically operates in one of two modes, static or dynamic.
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.
$ cc -dn -r -o temp.o file1.o file2.o file3.o ..... |
The use of static executables is limited. Static executables usually contain platform-specific implementation details which restricts the ability of the executable to be run on an alternative platform. Also, many implementations of Solaris libraries depend on dynamic linking capabilities, such as dlopen(3X) and dlsym(3X). (See "Loading Additional Objects".) These capabilities are not available to static executables.
Use the -dn option without the -r option:
$ cc -dn -o prog file1.o file2.o file3.o ..... |
The -a option is available to indicate the creation of a static executable; however, the use of -dn without a -r implies -a.
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 (see "Linking With a Mix of Shared Objects and Archives").
Use the -G option (-dy is optional as it is implied by default).
Input relocatable objects should be built from position-independent code. Use the -z text option to enforce this requirement (see "Position-Independent Code").
Establish the shared objects public interface by defining the global symbols that should be visible from this shared object, and reducing any other global symbols to local scope. This definition is provided by the -M option together with an associated mapfile, and is covered in more detail in Appendix B, Versioning Quick Reference.
Use a versioned name for the shared object to allow for future upgrades (see "Coordination of Versioned Filenames").
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 (see "Shared Objects With Dependencies").
Self-contained shared objects offer maximum flexibility, and are produced when the object expresses all dependency needs. Use the -z defs to enforce this self containment (see "Generating a Shared Object").
Optimize relocation processing by placing all relocations into the single .SUNW_reloc section. Use the -z combreloc option.
Avoid unneeded dependencies; use the -z ignore option, which requires the link-editor to only record dependencies to objects which are referenced.
The following example combines the above points:
$ cc -c -o foo.o -Kpic foo.c $ cc -M mapfile -G -o libfoo.so.1 -z text -z defs \ -z combreloc -z ignore -R /home/lib foo.o -L. -lbar -lc |
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 (see "Recording a Shared Object Name").
Make the shared object available to the compilation environment by creating a file system link to a non-versioned shared object name (see "Coordination of Versioned Filenames").
The following example combines the above points:
$ cc -M mapfile -G -o libfoo.so.1 -z text -z defs \ -zcombreloc -z ignore -R /home/lib-h libfoo.so.1 foo.o -lc $ ln -s libfoo.so.1 libfoo.so |
Consider the performance implications of the shared object; maximize shareability (see "Maximizing Shareability") and minimize paging activity (see "Minimizing Paging Activity"), reduce relocation overhead, especially by minimizing symbolic relocations (see "Profiling Shared Objects"), and allow access to data via functional interfaces (see "Copy Relocations").
Don't use the -G, or -dn options.
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 (see "Directories Searched by the Runtime Linker").
The following example combines the above points:
$ cc -o prog -R /home/lib -z ignore -L. -lfoo file1.o file2.o file3.o ..... |