Skip Navigation Links | |
Exit Print View | |
Linker and Libraries Guide Oracle Solaris 10 1/13 Information Library |
Part I Using the Link-Editor and Runtime Linker
1. Introduction to the Oracle Solaris Link Editors
Specifying the Link-Editor Options
Linking With Additional Libraries
Linking With a Mix of Shared Objects and Archives
Position of an Archive on the Command Line
Directories Searched by the Link-Editor
Directories Searched by the Runtime Linker
Initialization and Termination Sections
Generating an Executable Output File
Generating a Shared Object Output File
Tentative Symbol Order Within the Output File
Defining Additional Symbols with the -u option
Augmenting a Symbol Definition
Identifying Capability Requirements
Identifying a Platform Capability
Identifying a Machine Capability
Identifying Hardware Capabilities
Identifying Software Capabilities
Creating a Family of Symbol Capabilities Functions
Creating a Family of Symbol Capabilities Data Items
Converting Object Capabilities to Symbol Capabilities
Exercising a Capability Family
5. Link-Editor Quick Reference
7. Building Objects to Optimize System Performance
10. Establishing Dependencies with Dynamic String Tokens
Part IV ELF Application Binary Interface
13. Program Loading and Dynamic Linking
A. Linker and Libraries Updates and New Features
You can either run the link-editor directly from the command line or have a compiler driver invoke the link-editor for you. In the following two sections the description of both methods are expanded. However, using the compiler driver is the preferred choice. The compilation environment is often the consequence of a complex and occasionally changing series of operations known only to compiler drivers.
When you invoke the link-editor directly, you have to supply every object file and library required to create the intended output. The link-editor makes no assumptions about the object modules or libraries that you meant to use in creating the output. For example, the following command instructs the link-editor to create a dynamic executable that is named a.out using only the input file test.o.
$ ld test.o
Typically, a dynamic executable requires specialized startup code and exit processing code. This code can be language or operating system specific, and is usually provided through files supplied by the compiler drivers.
Additionally, you can also supply your own initialization code and termination code. This code must be encapsulated and be labeled correctly for the code to be correctly recognized and made available to the runtime linker. This encapsulation and labeling can also be provided through files supplied by the compiler drivers.
When creating runtime objects such as executables and shared objects, you should use a compiler driver to invoke the link-editor. Direct invocation of the link-editor is recommended only when creating intermediate relocatable objects when using the -r option.
The conventional way to use the link-editor is through a language-specific compiler driver. You supply the compiler driver, cc(1), CC(1), and so forth, with the input files that make up your application. The compiler driver adds additional files and default libraries to complete the link-edit. These additional files can be seen by expanding the compilation invocation.
$ cc -# -o prog main.o /usr/ccs/bin/ld -dy /opt/COMPILER/crti.o /opt/COMPILER/crt1.o \ /usr/ccs/lib/values-Xt.o -o prog main.o \ -YP,/opt/COMPILER/lib:/usr/ccs/lib:/usr/lib -Qy -lc \ /opt/COMPILER/crtn.o
Note - The actual files included by your compiler driver and the mechanism used to display the link-editor invocation might differ.
The link-editor is provided as a 32–bit application and a 64–bit application. Each link-editor can operate on 32–bit objects and 64–bit objects. However, a link-edit can not contain a mix of 32–bit objects and 64–bit objects. Although a 32–bit link-editor can generate a 64–bit object, the size of the generated object, not including the .bss, is restricted to 2 Gbytes.
By default, the compiler drivers execute the 32–bit link-editor. This link-editor inspects the command line to determine whether the 64–bit link-editor should be executed to complete the link-edit.
Typically, no command line option is required to distinguish a 32–bit link-edit or 64–bit link-edit. The link-editor uses the ELF class of the first relocatable object on the command line to govern the mode in which to operate. Specialized link-edits, such as linking solely from a mapfile or an archive library, are uninfluenced by the command line object. These link-edits default to a 32–bit mode, and require a command line option to instigate a 64–bit link-edit.
The 64–bit link-editor is executed under one of the following conditions.
The first relocatable object on the command line is 64–bit.
The creation of very large 32–bit objects can exhaust the virtual memory that is available to the 32–bit link-editor. The -z altexec64 option can be used to force the use of the associated 64–bit link-editor. The 64–bit link-editor provides a larger virtual address space for building 32–bit objects.
The link-editor is a cross link-editor, able to link 32–bit objects or 64–bit objects, for SPARC or x86 targets. The mixing of 32–bit objects and 64–bit objects is not permitted. Similarly, only objects of a single machine type are allowed.
Typically, no command line option is required to distinguish the link-edit target. The link-editor uses the ELF machine type of the first relocatable object on the command line to govern the mode in which to operate. Specialized link-edits, such as linking solely from a mapfile or an archive library, are uninfluenced by the command line object. These link-edits default to a 32–bit native target. To explicitly define the link-edit target use the -z target option.