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

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 -64 option is used.

• The -z altexec64 option is used.

• 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 LD_ALTEXEC environment variable can also be used to specify an alternative link-editor.