Confidential computer software. Valid license from HP required for possession, use or copying. Consistent with FAR 12.211 and 12.212, Commercial
Computer Software, Computer Software Documentation, and Technical Data for Commercial Items are licensed to the U.S. Government under
vendor's standard commercial license. The information contained herein is subject to change without notice. The only warranties for HP products
and services are set forth in the express warranty statements accompanying such products and services. Nothing herein should be construed as
constituting an additional warranty. HP shall not be liable for technical or editorial errors or omissions contained herein. UNIX is a registered
trademark of The Open Group.
Itanium® is a trademark of Intel Corporation in the U.S. and other countries.
Contents
About This Document...................................................................................13
This document discusses the most recent product information on HP-UX Linker and Libraries Version
B.11.72 for HP 9000 systems and Version B.12.57 for Integrity systems that are running HP-UX
11i v1, HP-UX 11i v2, and HP-UX 11i v3.
Intended Audience
This document is intended for developers who want to compile, link, and build applications using
the HP C/ANSI C Developer's Bundle on HP 9000 or HP Integrity systems.
Document conventions and symbols
Table 1 (page 13) lists the conventions and symbols used in this white paper.
Table 1 Document conventions
ElementConvention
Cross-reference links and email addressesMedium blue text:
Website addressesMedium blue, underlined text
(http://www.hp.com)
Bold font
Monospace font
Monospace, italic font
Monospace, bold font
• Key names
• Text typed into a GUI element, such as into a box
• GUI elements that are clicked or selected, such as menu and list items,
buttons, and check boxes
Text emphasisItalic font
• File and directory names
• System output
• Code
• Text typed at the command line
• Code variables
• Command-line variables
Emphasis of file and directory names, system output, code, and text typed
at the command line
CAUTION:Indicates that failure to follow directions can result in damage to equipment or data.
IMPORTANT:Provides clarifying information or specific instructions.
NOTE:Provides additional information.
Related Information
The following documents provide more information:
•HP-UX Linker, Libraries, and Tools Versions B.11.72 and B.12.57 Release Notes
•Improving program startup with fastbind: White paper
The HP-UX Linker web page is at:
http://www.hp.com/go/linker
Intended Audience13
HP Encourages Your Comments
HP encourages your comments concerning this document. We are committed to providing
documentation that meets your needs. Send any errors found, suggestions for improvement, or
compliments to:
feedback@fc.hp.com
Include the document title, manufacturing part number, and any comment, error found, or suggestion
for improvement you have concerning this document.
Document Organization
This guide is organized into the following chapters:
This document is organized as follows:
•“Compiling and Linking Programs on HP-UX” (page 16)
This chapter describes the process of compiling and linking programs on HP-UX. An example
is used to illustrate the process. The sections here describe the process of creating an executable
file and explain how ld creates an executable file from one or more object files. This chapter
also describes the conventions for using libraries with ld, describes the process of loading
and binding programs at run time, and explains the thread-safe features of linker. In addition,
it explains the means by which you can control how the linker links your programs or libraries.
•“Determining How to Link Programs or Libraries (Linker Tasks)” (page 27)
This chapter describes the tasks you can perform using the Compiler commands and Linker
commands. The tasks help you determine how the linker must link your program or library.
•“Linker Tools for Itanium-Based Systems” (page 53)
This chapter describes the linker toolset available for IA systems. The linker toolset provides
several tools to help you find symbols, display and modify object files, and determine link
order.
•“Linker Tools for PA-RISC Systems” (page 69)
This chapter describes the linker toolset available for PA-RISC systems. The linker toolset
provides several tools to help you find symbols, display and modify object files, and determine
link order.
•“Linker Toolset Differences Between PA-RISC and Itanium-Based Systems” (page 79)
This chapter describes some of the linker toolset differences between PA-RISC and Itanium-based
systems. This chapter also describes linker options specific to PA64 mode, symbols reserved
by linker, system library location, changes to the library name extension, and dynamic path
searching for shared libraries.
•“Creating and Using Libraries” (page 89)
This chapter provides an overview of shared and archived libraries, explains creating and
using libraries on HP-UX, and describes how to use shared libraries for programs in IA.
•“Shared Library Management Routines” (page 136)
This chapter explains shared library header files, initializers for shared libraries, and the
various shared library management routines.
14
•“Writing and Generating Position-Independent Code” (page 185)
This chapter is applicable to only PA-RISC 32-bit applications. The chapter explains relocatable
object code, absolute object code, and position-independent code. The chapter also explains
how to generate position-independent code.
•“Using Mapfiles” (page 191)
This chapter explains how to use mapfiles. The mapfile option, which is an advanced feature
of the linker toolset, is intended for use in system programming.
•“Improving Your Application Performance” (page 202)
This chapter explains how you can use linker to improve the performance of your applications.
This chapter discusses options to improve TLB hit rates, incremental linking, profile-based
optimization, and other ways to improve application performance.
•Glossary
The glossary provides definitions of terms listed alphabetically.
Document Organization15
1 Compiling and Linking Programs on HP-UX
This chapter describes the process of compiling and linking a program.
DescriptionSection
Provides an overview of compiling on HP-UX.“Compiling Programs on HP-UX: An Example”
(page 16)
Describes how ld creates an executable file from one or more object.“Linking Programs on HP-UX” (page 21)
Describes conventions for using libraries with ld.“Linking with Libraries” (page 23)
Describes the process of loading and binding programs at run time.“Running the Program” (page 25)
Describes the thread-safe features.“Linker Thread-Safe Features” (page 26)
Compiling Programs on HP-UX: An Example
This chapter addresses the following:
•“Overview” (page 16)
•“Looking Inside a Compiler” (page 18)
•“Compiler-Linker Interaction” (page 19)
Overview
To create an executable program, you compile a source file containing a main program. For
example, to compile an ANSI C program named sumnum.c, shown below, use this command
(-Aa says to compile in ANSI mode):
$ cc -Aa sumnum.c
The compiler displays status, warning, and error messages to standard error output (stderr). If
no errors occur, the compiler creates an executable file named a.out in the current working
directory. If your PATH environment variable includes the current working directory, you can run
a.out as follows:
$ a.out
Enter a number: 4
Sum 1 to 4: 10
The process is essentially the same for all HP-UX compilers. For instance, to compile and run a
similar FORTRAN program named sumnum.f:
$ f90 sumnum.f
//Compile and link sumnum.f.
... //The compiler displays any messages here.
$ a.out
//Run the program.
...
//Output from the program is displayed here.
Program source can also be divided among separate files. For example, sumnum.c could be
divided into two files: main.c, containing the main program, and func.c, containing the function
sum_n. The command for compiling the two together is:
$ cc -Aa main.c func.c
main.c:
func.c:
16Compiling and Linking Programs on HP-UX
Notice that cc displays the name of each source file it compiles. This way, if errors occur, you
know where they occur. Also, the diagnostics mention the name of the source file.
#include <stdio.h>
/* contains standard I/O defs */
int sum_n( int n )
/* sum numbers from n to 1 */
{
int sum = 0;
/* running total; initially 0 */
for (; n >= 1; --n)
/* sum from n to 1 */
sum += n;
/* add n to sum */
return sum;
/* return the value of sum */
}
int main()
/* begin main program
*/
{
int n;
/* number to input from user */
printf("Enter a number: ");
/* prompt for number */
scanf("%d", &n);
/* read the number into n */
printf("Sum 1 to %d: %d\\n", n, sum_n(n)); /* display the sum */
}
Generally speaking, the compiler reads one or more source files, one of which optionally contains
a main program, and outputs an executable named a.out by default unless a name is specified,
as shown in Figure 1.
Compiling Programs on HP-UX: An Example17
Figure 1 High-level View of the Compiler
Looking Inside a Compiler
On the surface, it appears as though an HP-UX compiler generates an a.out file by itself. Actually,
an HP-UX compiler is a driver that calls other commands to create the a.out file. The driver
performs different tasks (or phases) for different languages, but two phases are common to all
languages:
1.For each source file, the driver calls the language compiler to create an object file. (See also
“What is an Object File?” (page 18))
2.The HP-UX linker (ld) links the specified object files to create either a reusable object file, also
called a shared library, or an executable, which is named a.out by default unless a name
is specified. (See also “Compiler-Linker Interaction” (page 19).)
Figure 2 summarizes how a compiler driver works.
Figure 2 Looking Inside a Compiler
The C, aC++, and Fortran90 compilers provide the -v (verbose) option to display the phases a
compiler is performing.
What is an Object File?
An object file is basically a file containing machine language instructions and data in a form that
the linker can use to create an executable program. Each routine or data item defined in an object
file has a corresponding symbol name by which it is referenced. A symbol generated for a routine
18Compiling and Linking Programs on HP-UX
or data definition can be either a local definition or global definition. Any reference to a symbol
outside the object file is known as an external reference.
To keep track of where all the symbols and external references occur, an object file has a symbol
table. The linker uses the symbol tables of all input object files to match external references to
global definitions.
Local Definitions
A local definition is a definition of a routine or data that is accessible only within the object file in
which it is defined. Such a definition cannot be accessed from another object file. Local definitions
are used primarily by debuggers, such as adb. More important for this discussion are the global
definitions and external references.
Global Definitions
A global definition is a definition of a procedure, function, or data item that can be accessed by
code in another object file. For example, the C compiler generates global definitions for all variable
and function definitions that are not static. The FORTRAN compiler generates global definitions
for subroutines and common blocks. In Pascal, global definitions are generated for external
procedures, external variables, and global data areas for each module.
External References
An external reference is an attempt by code in one object file to access a global definition in
another object file. A compiler cannot resolve external references because it works on only one
source file at a time. Therefore, the compiler simply places external references in an object file's
symbol table; the matching of external references to global definitions is left to the linker or loader.
Compiler-Linker Interaction
As described in “Looking Inside a Compiler” (page 18), the compilers automatically call the linker
to create an executable file. To see how the compilers call ld, run the compiler with the -v (verbose)
option.
For example, compiling a C program to produce an IPF 32-bit share-bound application, produces
the output below:
$ cc -v main.c func.c -lm
main.c:
/opt/ansic/lbin/ecom -ia64abi all -architecture 32 -ext on -lang c \
-exception off -sysdir /usr/include - inline_power 1 -link_type dynamic \
-fpeval float - tls_dyn on -target_os 11.23 --sys_include /usr/include \
This example shows that the cc driver calls the actual C compiler (/opt/ansic/lbin/ecom)
for each source file. Then the driver calls the linker (/usr/ccs/bin/ld) on the object files
created by the compiler (main.o and func.o).
The next-to-last line in the above example is the command line that the compiler used to invoke the
linker, /usr/ccs/bin/ld. When building a share-bound executable, the startup functions are
handled by the dynamic loader dld. By default, the dynamic loader is found in /usr/lib/hpux32.
Thus, in most cases, the ld command does not include crtO.o. In the ld command line, ld
combines the two object files created by the compiler (main.o and func.o). It also searches the
libm (-lm) and libc (-lc) libraries.
On PA-RISC systems, the same compile command invokes the PA32 linker. The output is shown
below.
$ cc -Aa -v main.c func.c -lm
cc: CCOPTS is not set.
main.c:
/opt/langtools/lbin/cpp.ansi main.c /var/tmp/ctmAAAa10102 \
-D__unix -D_PA_RISC1_1
cc: Entering Preprocessor.
/opt/ansic/lbin/ccom /var/tmp/ctmAAAa10102 func.o -O0 -Aa
cc: LPATH is /usr/lib/pa1.1:/usr/lib:/opt/langtools/lib:
/usr/ccs/bin/ld /opt/langtools/lib/crt0.o -u main main.o func.o -lm -lc
cc: Entering Link editor.
The next-to-last line in the above example is the command line the compiler used to invoke the
PA32 mode linker, /usr/ccs/bin/ld. In this command, ld combines a startup file (crt0.o)
and the two object files created by the compiler (main.o and func.o) Also, ld searches the
libm and libc libraries.
For PA64 and IPF executables, the startup functions are handled by the dynamic loader. In most
cases, the ld command line does not include crt0.o.
20Compiling and Linking Programs on HP-UX
Linking Programs on HP-UX
•“The crt0.o Startup File” (page 21)
•“The a.out File” (page 22)
•“Magic Numbers (PA-RISC ONLY)” (page 22)
•“File Permissions” (page 23)
The HP-UX linker (ld) creates an executable file, shared library, or combines the object files to
create another relocatable object file. In doing so, it matches external references to global definitions
contained in other object files or libraries. It revises code and data to reflect new addresses. This
process is known as relocation. If the input files contain debugger information, ld updates this
information appropriately. The linker places the resulting executable code in a file named, by
default, a.out.
In the C program example, (see “Compiling Programs on HP-UX: An Example” (page 16) ) main.o
contains an external reference to sum_n, which has a global definition in func.o.
The linker (ld) matches the external reference to the global definition, allowing the main program
code in a.out to access sum_n (see Figure 3 (page 21)).
Figure 3 Matching the External Reference to sum_n
If the linker (ld) cannot match an external reference to a global definition, it displays a message
to standard error output. If, for instance, you compile main.c without func.c, the linker (ld)
cannot match the external reference to sum_n and displays this output:
$ cc -Aa main.c
ld: Unsatisfied symbol "func1" in file main.o
1 errors.
The crt0.o Startup File
Notice that in the PA32 example in “Compiler-Linker Interaction” (page 19) the first object file on
the linker command line is /opt/langtools/lib/crt0.o, even though this file was not specified
on the compiler command line. This file, known as a startup file, contains the program's entrypoint. The program's entry point is is the location at which the program starts running after HP-UX
loads it into memory to begin execution. The startup code does such things as retrieving command
line arguments into the program at run time, and activating the dynamic loader to load any required
shared libraries. In the C language, it also calls the routine _start in libc which, in turn, calls
the main program as a function.
Linking Programs on HP-UX21
The linker uses four startup files:
•32-bit PA is /opt/langtools/lib/crt0.o
•64-bit PA is /opt/langtools/lib/pa_64/crt0.o
The linker uses this startup file when it is in compatibility mode (+compat) or it is in default
standard mode (+std) with the -noshared option.
•32-bit IPF is /opt/langtools/lib/hpux32/crt0.o
The linker uses this startup file when it is in default standard mode (+std) with the -noshared
option.
•64-bit IPF is /opt/langtools/lib/hpux64/crt0.o
The linker uses this startup file when it is in default standard mode (+std) with the -noshared
option.
If the -p profiling option is specified on the compile line, the compilers link with -L
/usr/ccs/lib/libp -lprof. If the-G profiling option is specified, the compilers link with
/usr/ccs/lib/lip -lgprof.
PA-RISC ONLY:
If the linker option -I is specified to create an executable file with profile-based optimization, in
32-bit mode icrt0.o is used, and in 64-bit mode the linker inserts
/usr/ccs/lib/pa20_64/fdp_init.o. If the linker options -I and -b are specified to create
a shared library with profile-based optimization, in 32-bit mode scrt0.o is used, and in 64-bit
mode, the linker inserts /usr/ccs/lib/pa20_64/fdp_init-sl.o. In 64-bit mode, the linker
uses the single 64-bit crt0.o to support these options.
For details on startup files, see crt0(3).
The Program's Entry Point
For archive-bound (using the -complete compiler option or the -noshared linker option)
executables, the entry point is the location at which execution begins in the a.out file. The entry
point is defined by the symbol $START$ in crt0.o. In share-bound executables, the entry point
is defined by the symbol $START$ in the dynamic loader (dld.so).
The a.out File
The information contained in the resulting a.out file depends on which architecture the file was
created on and what options were used to link the program. In any case, an executable a.out
file contains information that HP-UX needs when loading and running the file. For example: Is it a
shared executable? Does it reference shared libraries? Is it demand-loadable? Where do the text
(code), data, and bss (uninitialized data) segments reside in the file? For details on the format of
this file, see a.out(4).
Magic Numbers (PA-RISC ONLY)
In 32-bit mode, the linker records a magic number with each executable program that determines
how the program should be loaded. There are three possible values for an executable file's magic
number:
SHARE_MAGICThe program's text (code) can be shared by processes; its data cannot be
shared. The first process to run the program loads the entire program into virtual
memory. If the program is already loaded by another process, then a process
shares the program text with the other process.
DEMAND_MAGICAs with SHARE_MAGIC the program's text is shareable but its data is not.
However, the program's text is loaded only as needed - that is, only as the
pages are accessed. This improves process startup time since the entire
22Compiling and Linking Programs on HP-UX
program does not need to be loaded; however, it can degrade performance
throughout execution.
EXEC_MAGICNeither the program's text nor data is shareable. In other words, the program is
an unshared executable. Usually, it is not desirable to create such unshared
executables because they place greater demands on memory resources.
By default, the linker creates executables whose magic number is SHARE_MAGIC. Table 2 (page
23) shows which linker option to use to specifically set the magic number.
Table 2 32-bit Mode Magic Number Linker Options
Use the optionTo set the magic number to
-nSHARE_MAGIC
-qDEMAND_MAGIC
-NEXEC_MAGIC
An executable file's magic number can also be changed using the chatr command (see “Changing
a Program's Attributes with chatr(1)” (page 53) ). However, chatr can only toggle between
SHARE_MAGIC and DEMAND_MAGIC; it cannot be used to change from or to EXEC_MAGIC. This
is because the file format of SHARE_MAGIC and DEMAND_MAGIC is exactly the same, while
EXEC_MAGIC files have a different format. For details on magic numbers, refer to magic(4).
In 64-bit mode, the linker sets the magic number to the predefined type for ELF object files
(\177ELF). The value of the e_type field in the ELF object file header specifies how the file should
be loaded.
File Permissions
If linker errors do not occur, the linker gives the a.out file read/write/execute permissions to all
users (owner, group, and other). If errors occur, the linker gives read/write permissions to all users.
Permissions are further modified if the umask is set (see umask(1)). For example, on a system with
umask set to 022, a successful link produces an a.out file with read/write/execute permissions
for the owner, and read/execute permissions for group and others:
$ umask
022
$ ls -l a.out
-rwxr-xr-x
1 michael
users
74440 Apr
4 14:38 a.out
Linking with Libraries
•“Library Naming Conventions” (page 24)
•“Default Libraries” (page 24)
•“Link Order” (page 24)
In addition to matching external references to global definitions in object files, the linker (ld)
matches external references to global definitions in libraries. A library is a file containing object
code for subroutines and data that can be used by other programs. For example, the standard C
library, libc, contains object code for functions that can be used by C, C++, FORTRAN, and
Pascal programs to do input, output, and other standard operations.
Linking with Libraries23
Library Naming Conventions
By convention, library names have the form:
libname. suffix
nameis a string of one or more characters that identifies the library.
suffixis .a if the library is an archive library, .sl if the library is a PA-RISC shared library,
or .so if the library is a shared library. (The suffix can be .sl for an IPF shared library.
This naming convention is not recommended, but it is supported for backwards
compatibility with PA-32 and PA-64.)
Typically, library names are referred to without the suffix. For instance, the standard C library is
referred to as libc.
Default Libraries
A compiler driver automatically specifies certain default libraries when it invokes ld. For example,
cc automatically links in the standard library libc, as shown by the -lc option to ld in this example:
Following are the default search paths for the libraries:
•On Itanium systems, ld searches for libraries in the directory /usr/lib/hpux32 for 32-bit
executables and /usr/lib/hpux64 for 64-bit executables.
•On PA-RISC systems, ld searches for libraries in the directory /usr/lib/ for 32-bit
executables and /usr/lib/pa20_64/ for 64-bit executables.
If the -p or -G compiler profiling option is specified on the command line, the compiler directs the
linker to also search:
/usr/lib/libp (for PA32)
/usr/lib/pa20__64/libp (for PA64)
/usr/lib/hpux32/libp (for IPF 32-bit)
/usr/lib/hpux64/libp (for IPF 64-bit)
The default order can be overridden with the LPATH environment variable, the -L linker option,
specifies $ORIGIN in the library path, or the +origin option. These are described in Changing
the“Changing the Default Library Search Path with -L, LPATH, and $ORIGIN” (page 30) .
Link Order
The linker searches libraries in the order in which they are specified on the command line - the
link order. Link order is important in that a library containing an external reference to another
library must precede the library containing the definition. This is why libc is typically the last
24Compiling and Linking Programs on HP-UX
library specified on the linker command line: because the other libraries preceding it in the link
order often contain references to libc routines and so must precede it.
NOTE:If multiple definitions of a symbol occur in the specified libraries, ld does not necessarily
choose the first definition. It depends on whether the program is linked with archive libraries,
shared libraries, or a combination of both. Depending on link order to resolve such library definition
conflicts is risky because it relies on undocumented linker behavior that may change in future
releases. (See also “Caution When Mixing Shared and Archive Libraries” (page 118).)
Running the Program
•“Loading Programs: exec” (page 25)
•“Binding Routines to a Program” (page 25)
•“Deferred Binding is the Default” (page 25)
An executable file is created after the program has been compiled and linked. The next step is to
run or load the program.
Loading Programs: exec
When you run an executable file created by ld, the program is loaded into memory by the HP-UX
program loader, exec. This routine is actually a system call and can be called by other programs
to load a new program into the current process space. The exec function performs many tasks;
some of the more important ones are:
•Determining how to load the executable file by looking at its magic number. (See also“The
a.out File” (page 22).)
•Determining where to begin execution of the program - that is, the entry point - For examples
in share-bound executables in dld.so, in archive-bound executables in crt0.o. (See also
“The crt0.o Startup File” (page 21).)
•When the program uses shared libraries, the crt0.o startup code invokes the dynamic loader,
which in turn attaches any required shared libraries. If immediate binding was specified at
link time, then the libraries are bound immediately. If deferred binding was specified, then
libraries are bound as they are referenced. (See also “What are Shared Libraries?” (page
91).)
For details on exec, see the exec(2) page in the HP-UX Reference.
Binding Routines to a Program
Since shared library routines and data are not actually contained in the a.out file, the dynamic
loader must attach the routines and data to the program at run time. Attaching a shared library
entails mapping the shared library code and data into the process's address space, relocating
any pointers in the shared library data that depend on actual virtual addresses, allocating the bsssegment, and binding routines and data in the shared library to the program.
The dynamic loader binds only those symbols that are reachable during the execution of the
program. This is similar to how archive libraries are treated by the linker; namely, ld pulls in an
object file from an archive library only if the object file is needed for program execution.
Deferred Binding is the Default
To accelerate program startup time, routines in a shared library are not bound until referenced.
(Data items are always bound at program startup.) This deferred binding of shared library routines
distributes the overhead of binding across the execution time of the program and is especially
expedient for programs that contain many references that are not likely to be executed. In essence,
deferred binding is similar to demand-loading.
Running the Program25
Linker Thread-Safe Features
The dynamic loader (dld) and its application interface library (libdl) are thread-safe.
Also, the linker toolset provides thread local storage support in:
•ld - the link editor
•crt0.o - the program startup file
Thread local storage (also called thread-specific data) is data specific to a thread. Each thread
has its own copy of the data item.
NOTE:Use of the __thread keyword in a shared library prevents that shared library from being
dynamically loaded, that is, loaded by an explicit call to shl_load().
For More Information:
•See your HP compiler documentation to learn how to create thread local storage data items
with the _thread compiler directive.
•See Programming with Threads on HP-UX for information on threads.
Shared library loading and unloading in multi-threaded applications
The dynamic loader serializes all calls to dlopen, dlclose, shl_load, and shl_unload using
a pthread mutex lock. A thread executing dlopen holds this lock, and another thread that wants
to execute dlclose (for example), even on a different shared library, must wait for the dlopen
in the first thread to release the lock after it is done.
Developers, who use these routines in multi-threaded applications (or shared libraries) and also
use mutex locks for synchronizing threads should take note of this behavior to avoid deadlock
situations. One example of such a situation is when a shared library initializer creates a new thread
that calls dlopen - this would invariably lead to a deadlock in a multi-threaded application. A
less trivial example could be as follows. Suppose thread A of an application calls dlopen to load
a shared library, libA. Now this shared library has an initializer initA that wants to obtain a
mutex lock M. But M is currently held by thread B of the application. Further, thread B wants to
load another library, libB and then release the mutex lock M. Now thread B would call either
dlopen or shl_load, either of which waits for the dld mutex lock to be released by the dlopen
called by thread A. In turn, thread A waits for mutex lock M to be released before it can finish
dlopen and release the dld mutex lock. This results in a deadlock.
26Compiling and Linking Programs on HP-UX
2 Determining How to Link Programs or Libraries (Linker
Tasks)
You have a great deal of control over how the linker links your program or library by using ld
command-line options. This chapter describes the tasks you can perform to determine how programs
and libraries must link by using the Compiler commands and Linker commands.
•“Using the Compiler to Link” (page 28)
“Changing the Default Library Search Path with -Wl, -L” (page 28)◦
◦“Getting Verbose Output with -v” (page 29)
◦“Passing Linker Options from the Compiler Command with -Wl” (page 29)
◦“Renaming the Output File with -o” (page 29)
◦“Specifying Libraries with -l” (page 29)
◦“Suppressing the Link-Edit Phase with -c” (page 30)
•“Using Linker Commands” (page 30)
“Linking with the crt0.o Startup File” (page 30)◦
◦“Changing the Default Library Search Path with -L, LPATH, and $ORIGIN” (page 30)
◦“Using $ORIGIN” (page 31)
◦“Changing the Default Shared Library Binding with -B” (page 32)
◦“Improving Shared Library Performance with -B symbolic” (page 34)
◦“Choosing Archive or Shared Libraries with -a” (page 36)
◦“Linking Shared Libraries with -dynamic” (page 36)
◦“Linking Archived Libraries with -noshared” (page 37)
◦“Exporting Symbols with +e” (page 37)
◦“Exporting Symbols with +ee” (page 38)
◦“Exporting Symbols from main with -E” (page 38)
◦“Hiding Symbols from Export with +hideallsymbols” (page 39)
◦“Hiding Symbols with -h” (page 39)
◦“ Not Recording Link Time Paths with +nodefaultrapth” (page 41)
◦“Moving Libraries after Linking with +b” (page 41)
◦“Moving Libraries After Linking with +s and SHLIB_PATH” (page 43)
◦“Ignoring Dynamic Path Environment Variables with +noenvvar” (page 43)
◦“Controlling Archive Library Loading with +[no]forceload” (page 44)
◦“Passing Linker Options in a file with -c” (page 44)
◦“Passing Linker Options with LDOPTS” (page 44)
27
◦“Specifying Libraries with -l and -l:” (page 45)
◦“Flagging Unsatisfied Symbols with +[no]allowunsats” (page 45)
◦“Stripping Symbol Table Information from the Output File with -s and -x” (page 46)
◦“Controlling Output from the Unwind Table with +strip unwind” (page 46)
◦“Using the IPF Linker with +compat or +std” (page 46)
◦“Linking in PA-64 Mode with +std” (page 48)
◦“Linking in PA-32 Mode with +compat” (page 48)
◦“Changing Mapfiles with -k and +nodefaultmap” (page 48)
◦“Selecting Verbose Output with +vtype” (page 48)
◦“Turning on the linkage table protection with +protect” (page 50)
◦“Allocating Storage for Uninitialized Data with +nobss” (page 50)
◦“Initializing Floating Point Environment with +FP ” (page 50)
◦“Allocating Storage for Hidden Common Symbols with +alloc_hidden_commons” (page
51)
◦“Turn Off Linker Warnings with -w” (page 52)
◦“Preserving Compiler Generated Relocation Sections with -emit_relocs” (page 52)
Using the Compiler to Link
In many cases, you use your compiler command to compile and link programs. Your compiler uses
options that directly affect the linker.
Changing the Default Library Search Path with -Wl, -L
The -L libpath option to ld augments the default search path; that is, it causes ld to search the
specified libpath before the default places. The C compiler (cc), the C++ compiler (CC), the POSIX
FORTRAN compiler (fort77), and the HP Fortran 90 compiler (f90) recognize the -L option and
pass it directly to ld. However, the HP FORTRAN compiler (f77) and Pascal compiler (pc) do not
recognize -L; it must be passed to ld with the -Wl option.
Example Using -Wl, -L
For example, to make the f77 compiler search /usr/local/lib to find a locally developed
library named liblocal, use this command line:
$ f77 prog.f -Wl,-L,/usr/local/lib -llocal
(The f77 compiler searches /opt/fortran/lib and /usr/lib as default directories.)
To make the f90 compiler search /usr/local/lib to find a locally developed library named
liblocal, use this command line:
$ f90 prog.f90 -L/usr/local/lib -llocal
(The f90 compiler searches /opt/fortran90/lib and /usr/lib as default directories.) For
the C compiler, use this command line:
$ cc -Aa prog.c -L /usr/local/lib -llocal
The LPATH environment variable provides another way to override the default search path. For
details, see “Changing the Default Library Search Path with -L, LPATH, and $ORIGIN” (page 30)
28Determining How to Link Programs or Libraries (Linker Tasks)
Getting Verbose Output with -v
The -v option makes a compiler display the verbose information. This is useful for viewing how
the compiler calls ld. For example, using the -v option with the C compiler shows that it
automatically links with libc.
$ cc -v himom.c
/opt/ansic/lbin/ecom -ia64abi all -architecture 32 -ext on -lang c \
-exception off -sysdir /usr/include -inline_power 1 -link_type dynamic \
-fpeval float -tls_dyn on -target_os 11.23 -- sys_include /usr/include \
Passing Linker Options from the Compiler Command with -Wl
The -Wl option passes options and arguments to ld directly, without the compiler interpreting the
options. Its syntax is:
-Wl,arg1 [,arg2]...
where each argn is an option or argument passed to the linker. For example, to make ld use the
archive version of a library instead of the shared, you must specify -a archive on the ld
command line before the library.
Example Using -Wl
The command for instructing the linker to use an archive version of libm from the C commandline is:
$ cc -Aa mathprog.c -Wl,-a,archive,-lm,-a,default
The command for instructing the linker to use an archive version of libm is:
$ $ ld /opt/langtools/lib/crt0.o mathprog.o -a archive -lm
-a default -lc
Renaming the Output File with -o
The -o name option causes ld to name the output file name instead of a.out. For example, to
compile a C program prog.c and name the resulting file sum_num:
$ cc -Aa -o sum_num prog.c //Compile using -o option.
$ sum_num //Run the program.
Enter a number to sum: 5
The sum of 1 to 5: 15
Specifying Libraries with -l
Sometimes programs call routines not contained in the default libraries. In such cases you must
explicitly specify the necessary libraries on the compile line with the -l option. The compilers pass
-l options directly to the linker before any default libraries, such as libc.
For example, if a C program calls library routines in the curses library (libcurses), you must
-u main -lc
cc: informational note 413: Entering Link editor.
Linking with the crt0.o Startup File in 32-bit mode (PA-RISC)
Notice also, in the above example, that the compiler linked cursesprog.o with the file
/opt/langtools/lib/crt0.o. This file contains object code that performs tasks which must
be executed when a program starts running - for example, retrieving any arguments specified on
the command line when the program is invoked. For details on this file, see “The crt0.o Startup
File” (page 21)
Suppressing the Link-Edit Phase with -c
The -c compiler option suppresses the link-edit phase. That is, the compiler generates only the .o
files and not the a.out file. This is useful when compiling source files that contain only subprograms
and data. These may be linked later with other object files, or placed in an archive or shared
library. The resulting object files can then be specified on the compiler command line, just like
source files. For example:
$ f90 -c func.f //Produce .o for func.f.
$ ls func.o
func.o
$ f90 main.f func.o //Compile main.f with func.o
$ a.out //Run it to verify it worked.
Using Linker Commands
This section describes linker commands for the 32-bit and 64-bit linker
NOTE:Unless otherwise noted, all examples show 32-bit behavior.
Linking with the crt0.o Startup File
In default mode, you need not include crt0.o on the link line. However, you must include crt0.o
on the link line for all fully archive links (ld -noshared) and in compatibility mode (+compat).
You need not include the crt0.o startup file on the ld command line for shared bound links. The
dynamic loader does some of the startup duties previously done by crt0.o.
See “The crt0.o Startup File” (page 21), and crt0(3) manpage for more information.
Changing the Default Library Search Path with -L, LPATH, and $ORIGIN
You can change or override the default linker search path by using the LPATH environment variable,
the -L linker option, or the +origin linker option.
Overriding the Default Linker Search Path with LPATH
The LPATH environment variable allows you to specify which directories ld should search. If
LPATH is not set, ld searches the default directory /usr/lib. If LPATH is set, ld searches only
the directories specified in LPATH; the default directories are not searched unless they are specified
in LPATH.
If set, LPATH must contain a list of colon-separated directory path names that ld must search. For
example, to include /usr/local/lib in the search path after the default directories, set LPATH
as follows:
30Determining How to Link Programs or Libraries (Linker Tasks)
Loading...
+ 198 hidden pages
You need points to download manuals.
1 point = 1 manual.
You can buy points or you can get point for every manual you upload.