JavaScript is required to for searching.
Skip Navigation Links
Exit Print View
Linker and Libraries Guide     Oracle Solaris 10 8/11 Information Library
search filter icon
search icon

Document Information

Preface

1.  Introduction to the Oracle Solaris Link Editors

2.  Link-Editor

Invoking the Link-Editor

Direct Invocation

Using a Compiler Driver

The 32-bit link-editor and 64-bit link-editor

Cross Link-Editing

Specifying the Link-Editor Options

Input File Processing

Archive Processing

Shared Object Processing

Linking With Additional Libraries

Library Naming Conventions

Linking With a Mix of Shared Objects and Archives

Position of an Archive on the Command Line

Directories Searched by the Link-Editor

Using a Command-Line Option

Using an Environment Variable

Directories Searched by the Runtime Linker

Initialization and Termination Sections

Symbol Processing

Symbol Resolution

Simple Resolutions

Complex Resolutions

Fatal Resolutions

Undefined Symbols

Generating an Executable Output File

Generating a Shared Object Output File

Weak Symbols

Tentative Symbol Order Within the Output File

Defining Additional Symbols

Defining Additional Symbols with the -u option

Defining Symbol References

Defining Absolute Symbols

Defining Tentative Symbols

Augmenting a Symbol Definition

Reducing Symbol Scope

Symbol Elimination

External Bindings

String Table Compression

Generating the Output File

Identifying Capability Requirements

Identifying a Platform Capability

Identifying a Machine Capability

Identifying Hardware Capabilities

Identifying Software Capabilities

Software Capability Frame Pointer Processing

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

Relocation Processing

Displacement Relocations

Stub Objects

Debugging Aids

3.  Runtime Linker

4.  Shared Objects

5.  Application Binary Interfaces and Versioning

6.  Support Interfaces

7.  Object File Format

8.  Thread-Local Storage

9.  Mapfiles

A.  Link-Editor Quick Reference

B.  Versioning Quick Reference

C.  Establishing Dependencies with Dynamic String Tokens

D.  Direct Bindings

E.  System V Release 4 (Version 1) Mapfiles

F.  Linker and Libraries Updates and New Features

Index

Invoking the Link-Editor

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.

Direct Invocation

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.

Using a Compiler Driver

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 32–bit link-editor and 64–bit link-editor

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


Note - The LD_ALTEXEC environment variable can also be used to specify an alternative link-editor.


Cross Link-Editing

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.