LD(1) LD(1)
NAME
ld - Mach object file link editor
SYNOPSIS
ld [ option ... ] [ file ... ]
DESCRIPTION
The ld command combines several Mach-O (Mach object) files
into one by combining like sections in like segments from
all the object files, resolving external references, and
searching libraries. In the simplest case several object
files are given, and ld combines them, producing an object
file which can either be executed or become the input for
a further ld run. (In the latter case, the -r option must
be given to preserve the relocation information.) Unless
an output file is specified, ld produces a file named
a.out. This file is made executable only if no errors
occurred during the link editing and there are no unde-
fined symbols.
FAT FILE SUPPORT
The link editor accepts ``fat'' (multiple-architecture)
input files, but always creates a ``thin'' (single-archi-
tecture), standard Mach-O output file. The architecture
is specified using the -arch arch_type option. If this
option is not used, ld(1) attempts to determine the output
architecture by examining the first object file encoun-
tered on the command line. If it is a ``thin'' file, its
architecture determines that of the output file. If the
first input file is a ``fat'' file, the ``best'' architec-
ture for the host is used. (See the explanation of the
-arch option, below.)
The compiler driver cc(1) handles creating fat executables
by calling ld(1) multiple times and using lipo(1) to cre-
ate a ``fat'' file from the results of the ld(1) execu-
tions.
OUTPUT FILE LAYOUT
The object files are loaded in the order in which they are
specified on the command line. The segments and the sec-
tions in those segments will appear in the output file in
the order they are encountered in the object files being
linked. All zero fill sections will appear after all non-
zero fill sections in their segments.
Sections created from files with the -sectcreate option
will appear in the output file last. Section names for
sections created from files are not allowed to overlap
with a section name in the same segment as a section com-
ing from an object file. Sections created from files may
be in a segment which has sections from object files and
if so will be loaded at the end of the non-zero fill sec-
tions for that segment.
If the option -seglinkedit is specified, the segment it
creates is the last segment in the output file.
The address of each segment can be specified with
-segaddr, which takes the segment's name as an argument.
The address of the first segment can alternatively be
specified using -seg1addr, in which case a segment name is
not used. Segments that do not have a specified address
will be assigned addresses in the order in which they
appear in the output file. A segment's address will be
assigned based on the ending address of the previous seg-
ment. If the address of the first segment has not been
specified by name, its assigned address will be the speci-
fied (via -seg1addr) or default first segment address. If
neither flag is used to specify the first segment's
address, its default address is zero for all formats
except the demand-paged executable format (MH_EXECUTE), in
which case the default first address is the value of the
segment alignment.
For demand-paged executable format (MH_EXECUTE) output
files, if none of the segments' addresses covers address
zero through the value of the segment alignment, a segment
with no access protection will be created to cover those
addresses. This segment, named ``__PAGEZERO'', is created
so that any attempt to dereference a NULL pointer will
cause a memory exception.
The entry point of the output file is the beginning of the
first section in the first segment (unless the -e option
is specified).
STATIC ARCHIVE LIBRARIES
ld supports two types of libraries: static archive
libraries and dynamic shared libraries. Searching for
undefined symbols is performed differently for dynamic
shared libraries than it is for static archive libraries.
The searching of dynamic shared libraries is described
later.
When a static archive library is specified as an argument
to ld, it is searched exactly once, at the point it is
encountered in the argument list. Only those members
defining an unresolved external reference, as defined by
the static archive library's table of contents, are
loaded. To produce the table of contents, all static
archive libraries must be processed by ranlib(1).
Generally, a static archive library does not have multiple
members that define the same symbol. For these types of
libraries, the order of the members is not important, so
the table of contents can be sorted for faster link edit-
ing using the -s option to ranlib(1). The first member of
the static archive library is named ``__.SYMDEF SORTED'',
which is understood to be a sorted table of contents.
If the static archive library does have multiple members
that define the same symbol, the table of contents that
ranlib(1) produces can't be sorted. Instead, it follows
the order in which the members appear in the static
archive library. The link editor searches the table of
contents iteratively, loading members until no further
references are satisfied. In the unsorted case, the first
member of the static archive library is named
``__.SYMDEF'', which is understood to be a table of con-
tents in the order of the archive members.
Static archive library members can also be loaded in
response to the -ObjC and -all_load flags. See their
descriptions below.
DYNAMIC SHARED LIBRARIES
When a dynamic shared library or an object file that was
linked against a dynamic shared library is specified as an
argument to ld, that library is placed in the dynamic
shared library search list. The order of the search list
is always the same order the libraries were encountered on
the command line. All dynamic libraries libraries that the
dynamic libraries are dependent upon are added to the end
of the search list.
Once the search list is constructed, the static link edi-
tor checks for undefined symbols by simulating the way the
dynamic linker will search for undefined symbols at run-
time. For each undefined symbol, the static link editor
searches each library in the search list until it finds a
module that defines the symbol. With each undefined sym-
bol, the search starts with the first library in the list.
This is different than for static archive libraries, where
each library is searched exactly once for all undefined
symbols.
The static link editor simulates dynamic linking as if all
the undefined symbols are to be bound at program launch
time. The dynamic linker actually binds undefined symbols
as they are encountered during execution instead of at
program launch. However, the static link editor always
produces the same linking as the dynamic linker as long as
none of the dynamic shared libraries define the same sym-
bol. Different linking can occur only when there is more
than one definition of a symbol and the library modules
that contain the definitions for that symbol do not define
and reference exactly the same symbols. In this case,
even different executions of the same program can produce
different linking because the dynamic linker binds unde-
fined functions as they are called, and this affects the
order in which undefined symbols are bound. Because it
can produce different dynamic linking, using dynamic
shared libraries that define the same symbols in the same
program is strongly discouraged.
If a static archive library appears after a dynamic shared
library on the command line, the static library is placed
in the dynamic library search list and is searched as a
dynamic library. In this way, when a dynamic library has
undefined symbols, it will cause the appropriate members
of the static libraries to be loaded into the output.
Searching static libraries as dynamic libraries can cause
problems if the dynamic library later changes to reference
symbols from the static library that it did not previously
reference. In this case when the program runs, the dynamic
linker will report these symbols as undefined because the
members for these symbols were not loaded into the output.
TWO-LEVEL AND FLAT NAMESPACES
Two-level and flat namespaces refer to how references to
symbols in dynamic libraries are resolved to a definition
in specific dynamic library. For two-level namespace that
resolution is done at static link time when each image
(program, bundle and shared library) is built. When a
program is using images built with two-level namespace
there may be different global symbols with the same name
being used by different images in the program (this is now
the default). When a program is using all flat namespace
images then only one global symbol for each global symbol
name is used by all images of the program (this was the
default in MacOS X 10.0).
When creating a output file with the static link editor
that links against dynamic libraries, the references to
symbols in those libraries can be recorded at static link
time to bind to a specific library definition (two-level
namespace) or left to be bound at execution time to the
first library in the search order of the program (flat
namespace). A program, its dynamic libraries and its bun-
dles may each be either two-level or flat namespace
images. The dynamic linker will bind each image according
to how it was built.
When creating a output file with the static link editor
when -twolevel_namespace is in effect (now the default)
all undefined references must be satisfied at static link
time. The flags to allow undefined references, -Usym-
bol_name, -undefined warning and -undefined suppress can't
be used. The specific library definition recorded for
each reference is the first library that has a definition
as listed on the link line. Listing an umbrella framework
implies all of its sub-frameworks, sub-umbrellas and sub-
libraries. For any reference to a definition found in an
umbrella framework's sub-framework, sub-umbrella or sub-
library will be recorded as coming from the umbrella
framework. Then at execution time the dynamic linker will
search that umbrella framework's sub-frameworks, sub-
umbrellas and sub-libraries for those references. Also
when two-level namespace is in effect only those frame-
works listed on the link line (and sub-frameworks, sub-
umbrellas and sub-libraries of umbrella frameworks) are
searched. Other dependent libraries which are not sub-
frameworks, sub-umbrellas or sub-libraries of umbrella
frameworks are not searched.
If a two-level namespace static link references a
symbol from an indirectly referenced dynamic
library not listed on the link line the following
error message will result:
ld: object_file illegal reference to symbol:
symbol defined in indirectly referenced
dynamic library: library
To correct the link error the user should add
library to the link line in the order he wants the
library to be searched.
When creating bundles (MH_BUNDLE outputs) with the static
link editor when two-level namespace is in effect (now the
default) and the bundle has references to symbols expected
to be defined in the program loading the bundle, then the
-bundle_loader executable must be used.
When creating a output file with the static link editor
when -flat_namespace is in effect (the MacOS X 10.0
default) all undefined references must be satisfied at
static link time when -undefined error (the default) is
used. The static link editor checks the undefined refer-
ences by searching all the libraries listed on the link
line then all dependent libraries. The undefined symbols
in the created output file are left to be resolved at exe-
cution time by the dynamic link editor in the dynamic
libraries in the search order of the program.
MULTIPLY DEFINED SYMBOLS
If there are multiply defined symbols in the object files
being linked into the output file being created this
always results in a multiply defined symbol error.
When the static link editor links symbols in from a
dynamic library that result in multiply defined symbols
the handling depends on the type of name space of output
file being created and possibly the type of name space of
the dynamic library.
When the static link editor is creating a two-level names-
pace image and a there is a multiply defined symbol from
dynamic library then that generates a multiply defined
symbol warning (by default), where the treatment of this
warning can be changed with the -multiply_defined flag.
When the static link editor is creating a flat namespace
image and a there is a multiply defined symbol from
dynamic library, if the library is a flat namespace image
then that generates a multiply defined symbol error. If
the library is a two-level namespace image then that gen-
erates a multiply defined symbol warning (by default),
where the treatment of this warning can be changed with
the -multiply_defined flag.
USING THE DYNAMIC LINK EDITOR AND DYNAMIC SHARED LIBRARIES
The option -dynamic must be specified in order to use
dynamic shared libraries (and any of the features used to
implement them) and/or the dynamic link editor. To make
sure that the output is not using any features that would
require the dynamic link editor, the flag -static can be
specified. Only one of these flags can be specified.
LINK EDITOR DEFINED SYMBOLS
There is a group of link editor defined symbols for the
MH_EXECUTE, MH_DYLIB and MH_PRELOAD file types (see the
header file <mach-o/ldsyms.h>). Link editor symbols are
reserved; it is an error if an input object file defines
such a symbol. Only those link editor symbols that are
referenced by the object file appear in the output file's
symbol table.
The link editor defined symbol `__mh_execute_header'
(`_mh_execute_header' in C) is reserved when the output
file format is MH_EXECUTE. This symbol is the address of
the Mach header in a Mach-O executable (a file of type
MH_EXECUTE). It does not appear in any other Mach-O file
type. It can be used to get to the addresses and sizes of
all the segments and sections in the executable. This can
be done by parsing the headers and load commands (see
Mach-O(5)).
The link editor defined symbol `__mh_dylib_header'
(`_mh_dylib_header' in C) is reserved when the output file
format is MH_DYLIB. This symbol is the address of the
Mach header in a Mach-O dynamic shared library (a file of
type MH_DYLIB) and is a private external symbol. It does
not appear in any other Mach-O file type. It can be used
to get to the addresses and sizes of all the segments and
sections in a dynamic shared library. The addresses, how-
ever, must have the value _dyld_get_image_vmaddr_slide(3)
added to them.
The MH_PRELOAD file type has link editor defined symbols
for the beginning and ending of each segment, and for the
beginning and ending of each section within a segment.
These names are provided for use in a Mach-O preloaded
file, since it does not have its headers loaded as part of
the first segment. The names of the symbols for a seg-
ment's beginning and end have the form: __SEGNAME__begin
and __SEGNAME__end, where __SEGNAME is the name of the
segment. Similarly, the symbols for a section have the
form: __SEGNAME__sectname__begin and __SEGNAME__sect-
name__end, where __sectname is the name of the section in
the segment __SEGNAME. These symbols' types are those of
the section that the names refer to. (A symbol that
refers to the end of a section actually has, as its value,
the beginning address of the next section, but the sym-
bol's type is still that of the section mentioned in the
symbol's name.)
OPTIONS
Ld understands several options. Filenames and options
that refer to libraries (such as -l and -framework), as
well as options that create symbols (such as -u and -i),
are position-dependent: They define the load order and
affect what gets loaded from libraries. Some ld options
overlap with compiler options. If the compiler driver
cc(1) is used to invoke ld , it maybe necessary to pass
the ld(1) options to cc(1) using -Wl,-option,argu-
ment1,argument2.
The most common option is:
-o name
The output file is named name, instead of a.out.
The following flags are related to architectures:
-arch arch_type
Specifies the architecture, arch_type, for the out-
put file. ``Fat'' input files that do not contain
this specified architecture are ignored. Only one
-arch arch_type can be specified. See arch(3) for
the currently known arch_types. If arch_type
specifies a certain implementation of an architec-
ture (such as -arch m68040 or -arch i486 ), the
resulting object file has that specific CPU sub-
type, and it is an error if any input file has a
CPU subtype that will not combine to the CPU sub-
type for arch_type.
The default output file architecture is determined
by the first object file to be linked. If it is a
``thin'' (standard Mach-O) file, or a ``fat'' file
that contains only one architecture, the output
file will have the same architecture. Otherwise,
if it is a ``fat'' file containing an architecture
that would execute on the host, then the ``best''
architecture is used, as defined by what the kernel
exec(2) would select. Otherwise, it is an error,
and a -arch arch_type must be specified.
-arch_multiple
This flag is used by the cc(1) driver program when
it is run with multiple -arch arch_type flags. It
instructs programs like ld(1) to precede any dis-
played message with a line stating the program
name, in this case ld, and the architecture (from
the -arch arch_type flag). This helps distinguish
which architecture the error messages refer to.
-force_cpusubtype_ALL
The -force_cpusubtype_ALL flag causes the CPU sub-
type to remain the ALL CPU subtype and not to be
combined or changed. This flag has precedence over
any -arch arch_type flag for a specific implementa-
tion.
The following flags are related to using the dynamic link
editor and/or dynamic shared libraries (and any of the
features used to implement them):
-dynamic
Allows use of the features associated with dynamic
link editor. The default is -dynamic.
-static
Causes those features associated with dynamic link
editor to be treated as an error. (The description
for the options that will cause an error if you use
them in conjunction with -static are marked with
the statement "when -dynamic
is used").
-read_only_relocs treatment
Specifies how relocation entries in read-only sec-
tions are to be treated when -dynamic is used. To
get the best possible sharing, the read-only sec-
tions should not have any relocation entries. If
they do, the dynamic linker will write on the sec-
tion. Having relocation entries appear in read-
only sections is normally avoided by compiling with
the option -dynamic. But in such cases non-con-
verted assembly code or objects not compiled with
-dynamic relocation entries will appear in read-
only sections. The treatment can be: error, warn-
ing, or suppress. Which cause the treatment of
relocation entries in read-only sections as either,
errors, warnings, or suppressed messages. The
default is to treat these as errors.
-sect_diff_relocs treatment
Specifies how section difference relocation enries
are to be treated when -dynamic and -execute are
used. To get the best possible code generation the
compiler should not generate code for executables
(MH_EXECUTE format outputs) that have any section
difference relocation entries. The gcc(1) compiler
has the -mdynamic-no-pic flag for generating code
for executables. The default treatment is sup-
press, where no message is printed. The other
treatments are error or warning. This option can
also be specified by setting the environment vari-
able LD_SECT_DIFF_RELOCS to the treatment values.
-weak_reference_mismatches treatment
Specifies how to treat mismatches of symbol refer-
ences in the the object files being linked. Nor-
mally the all the undefined symbol references of
the object files being linked should be consistent
for each undefined symbol. That is all undefined
symbols should either be weak or non-weak refer-
ences. The default treatment is error, where the
link fails with an error message. The other treat-
ments are weak or non-weak, which makes mismatched
undefined symbol references either weak or non-weak
respectfully in the output. Care must be taken
when using the treatment weak as the use of the
non-weak symbol references in an object file may
cause the program to crash when the symbol is not
present at execution time.
-prebind
Have the static linker, ld(1), prebind an exe-
cutable's or dynamic shared library's undefined
symbols to the addresses of the dynamic libraries
it is being linked with. This optimization can
only be done if the libraries don't overlap and no
symbols are overridden. When the resulting program
is run and the same libraries are used to run the
program as when the program was linked, the dynamic
linker can use the prebound addresses. If not, the
dynamic linker undoes the prebinding and binds nor-
mally. This option can also be specified by set-
ting the environment variable LD_PREBIND. If the
environment variable LD_FORCE_NO_PREBIND is set
both the option -prebind LD_PREBIND environment
variable are ignore and the output is not prebound.
and the
-noprebind
Do not have the static linker, ld(1), prebind the
output. If this is specified the environment vari-
able LD_PREBIND is ignored.
-prebind_allow_overlap
Have the static linker, ld(1), prebind the output
even if the addresses of the dynamic libraries it
uses overlap. The resulting output can then have
redo_prebinding(1) run on it to fix up the prebind-
ing after the overlapping dynamic libraries have
been rebuilt. This option can also be specified by
setting the environment variable LD_PRE-
BIND_ALLOW_OVERLAP.
-prebind_all_twolevel_modules
Have the static linker, ld(1), mark all modules
from prebound two-level namespace dynamic libraries
as used by the program even if they are not stati-
cally referenced. This can provide improved launch
time for programs like Objective-C programs that
use symbols indirectly through NIB files. This
option can also be specified by setting the envi-
ronment variable LD_PREBIND_ALL_TWOLEVEL_MODULES.
-nofixprebinding
Have the static linker, ld(1), mark the executable
so that the dynamic linker will never notify the
prebinding agent if this launched and its prebind-
ing is out of date. This is used when building the
prebinding agent itself.
The following flags are related to libraries:
-lx This option is an abbreviation for the library name
`libx.a', where x is a string. If -dynamic is
specified the abbreviation for the library name is
first search as `libx.dylib' and then `libx.a' is
searched for. ld searches for libraries first in
any directories specified with -L options, then in
the standard directories /lib, /usr/lib, and
/usr/local/lib. A library is searched when its
name is encountered, so the placement of the -l
flag is significant. If string x is of the form
x.o, then that file is searched for in the same
places, but without prepending `lib' or appending
`.a' or `.dylib' to the filename.
-Ldir Add dir to the list of directories in which to
search for libraries. Directories specified with
-L are searched before the standard directories.
-Z Do not search the standard directories when search-
ing for libraries.
-framework name[,suffix]
Specifies a framework to link against. Frameworks
are dynamic shared libraries, but they are stored
in different locations, and therefore must be
searched for differently. When this option is spec-
ified, ld searches for framework `name.frame-
work/name' first in any directories specified with
the -F option, then in the standard framework
directories /Library/Frameworks, /Net-
work/Library/Frameworks, and /System/Library/Frame-
works. The placement of the -framework option is
significant, as it determines when and how the
framework is searched. If the optional suffix is
specified the framework is first searched for the
name with the suffix and then without.
-Fdir Add dir to the list of directories in which to
search for frameworks. Directories specified with
-F are searched before the standard framework
directories.
-ObjC Loads all members of static archive libraries that
define an Objective C class or a category. This
option does not apply to dynamic shared libraries.
-all_load
Loads all members of static archive libraries.
This option does not apply to dynamic shared
libraries.
-dylib_file install_name:file_name
Specifies that a dynamic shared library is in a
different location than its standard location. Use
this option when you link with a library that is
dependent on a dynamic library, and the dynamic
library is in a location other than its default
location. install_name specifies the path where
the library normally resides. file_name specifies
the path of the library you want to use instead.
For example, if you link to a library that depends
upon the dynamic library libsys and you have libsys
installed in a nondefault location, you would use
this option: -dylib_file /lib/lib-
sys_s.A.dylib:/me/lib/libsys_s.A.dylib.
The following options specify the output file format (the
file type):
-execute
Produce a Mach-O demand-paged executable format
file. The headers are placed in the first segment,
and all segments are padded to the segment
alignment. This has a file type of MH_EXECUTE.
This is the default. If no segment address is
specified at address zero, a segment with no pro-
tection (no read, write, or execute permission) is
created at address zero. This segment, whose size
is that of the segment alignment, is named
``__PAGEZERO''. This option was previously named
-Mach, which will continue to be recognized.
-object
Produce a Mach-O file in the relocatable object
file format that is intended for execution. This
differs from using the -r option in that it defines
common symbols, does not allow undefined symbols
and does not preserve relocation entries. This has
a file type of MH_OBJECT. In this format all sec-
tions are placed in one unnamed segment with all
protections (read, write, execute) allowed on that
segment. This is intended for extremely small pro-
grams that would otherwise be large due to segment
padding. In this format, and all non-MH_EXECUTE
formats, the link editor defined symbol ``__mh_exe-
cute_header'' is not defined since the headers are
not part of the segment. This format file can't be
use with the dynamic linker.
-preload
Produce a Mach-O preloaded executable format file.
The headers are not placed in any segment. All
sections are placed in their proper segments and
they are padded to the segment alignment. This has
a file type of MH_PRELOAD. This option was previ-
ously -p, which will continue to be recognized.
-dylib Produce a Mach-O dynamically linked shared library
format file. The headers are placed in the first
segment. All sections are placed in their proper
segments and they are padded to the segment align-
ment. This has a file type of MH_DYLIB. This
option is used by libtool(1) when its -dynamic
option is specified.
-bundle
Produce a Mach-O bundle format file. The headers
are placed in the first segment. All sections are
placed in their proper segments and they are padded
to the segment alignment. This has a file type of
MH_BUNDLE.
-dylinker
Produces a Mach-O dynamic link editor format file.
The headers are placed in the first segment. All
sections are placed in their proper segments, and
they are padded to the segment alignment. This has
a file type of MH_DYLINKER.
-fvmlib
Produce a Mach-O fixed VM shared library format
file. The headers are placed in the first segment
but the first section in that segment will be
placed on the next segment alignment boundary in
that segment. All sections are placed in their
proper segments and they are padded to the segment
alignment. This has a file type of MH_FVMLIB.
The following flags affect the contents of the output
file:
-r Save the relocation information in the output file
so that it can be the subject of another ld run.
The resulting file type is a Mach-O relocatable
file (MH_OBJECT) if not otherwise specified. This
flag also prevents final definitions from being
given to common symbols, and suppresses the `unde-
fined symbol' diagnostics.
-d Force definition of common storage even if the -r
option is present. This option also forces link
editor defined symbols to be defined. This option
is assumed when there is a dynamic link editor load
command in the input and -r is not specified.
The following flags support segment specifications:
-segalign value
Specifies the segment alignment. value is a hex-
adecimal number that must be an integral power of
2. The default is the target pagesize (currently
1000 hex for the PowerPC and 2000 hex for i386).
-seg1addr addr
Specifies the starting address of the first segment
in the output file. addr is a hexadecimal number
and must be a multiple of the segment alignment.
This option can also be specified as -image_base.
-segaddr name addr
Specifies the starting address of the segment named
name to be addr. The address must be a hexadecimal
number that is a multiple of the segment alignment.
-segs_read_only_addr addr
Specifies the starting address of the read-only
segments in a dynamic shared library. When this
option is used the dynamic shared library is built
such that the read-only and read-write segments are
split into separate address ranges. By default the
read-write segments are 256meg (0x10000000) after
the read-only segments. addr is a hexadecimal num-
ber and must be a multiple of the segment align-
ment.
-segs_read_write_addr addr
Specifies the starting address of the read-write
segments in a dynamic shared library. When this
option is used the -segs_read_only_addr must also
be used (see above). addr is a hexadecimal number
and must be a multiple of the segment alignment.
-seg_addr_table filename
For dynamic shared libraries the -seg1addr or the
pair of -segs_read_only_addr and
-segs_read_write_addr are specified by an entry in
the segment address table in filename that matches
the install name of the library. The entries in
the table are lines containing either a single hex
address and an install name or two hex addresses
and an install name. In the first form the single
hex address is used as the -seg1addr . In the sec-
ond form the first address is used as the
-segs_read_only_addr address and the second address
is used as the -segs_read_write_addr address. This
option can also be specified by setting the envi-
ronment variable LD_SEG_ADDR_TABLE. If the envi-
ronment variable is set then any -seg1addr,
-segs_read_only_addr, -segs_read_write_addr and
-seg_addr_table options are ignored and a warning
is printed.
-seg_addr_table_filename pathname
Use pathname instead of the install name of the
library for matching an entry in the segment
address table.
-segprot name max init
Specifies the maximum and initial virtual memory
protection of the named segment, name, to be max
and init respectfully. The values for max and init
are any combination of the characters `r' (for
read), `w' (for write), `x' (for execute) and '-'
(no access). The default is `rwx' for the maximum
protection for all segments. The default for the
initial protection for all segments is `rw' unless
the segment contains a section which contains some
machine instructions, in which case the default for
the initial protection is `rwx'. The default for
the initial protection for the ``__TEXT'' segment
is `rx' (not writable).
-seglinkedit
Create the link edit segment, named ``__LINKEDIT''
(this is the default). This segment contains all
the link edit information (relocation information,
symbol table, string table, etc.) in the object
file. If the segment protection for this segment
is not specified, the initial protection is not
writable. This can only be specified when the out-
put file type is not MH_OBJECT and MH_PRELOAD out-
put file types. To get at the contents of this
section, the Mach header and load commands must be
parsed from the link editor defined symbols like
`__mh_execute_header' (see Mach-O(5)).
-noseglinkedit
Do not create the link edit segment (see
-seglinkedit above).
-pagezero_size value
Specifies the segment size of __PAGEZERO to be of
size value, where value is a hexadecimal number
rounded to the segment alignment. The default is
the target pagesize (currently, 1000 hexadecimal
for the PowerPC and 2000 hexadecimal for i386).
-stack_addr value
Specifies the initial address of the stack pointer
value, where value is a hexadecimal number rounded
to the segment alignment. The default segment
alignment is the target pagesize (currently, 1000
hexadecimal for the PowerPC and 2000 hexadecimal
for i386). If -stack_size is specified and
-stack_addr is not, a default stack address spe-
cific for the architecture being linked will be
used and its value printed as a warning message.
This creates a segment named __UNIXSTACK. Note
that the initial stack address will be either at
the high address of the segment or the low address
of the segment depending on which direction the
stack grows for the architecture being linked.
-stack_size value
Specifies the size of the stack segment value,
where value is a hexadecimal number rounded to the
segment alignment. The default segment alignment
is the target pagesize (currently, 1000 hexadecimal
for the PowerPC and 2000 hexadecimal for i386). If
-stack_addr is specified and -stack_size is not, a
default stack size specific for the architecture
being linked will be used and its value printed as
a warning message. This creates a segment named
__UNIXSTACK .
The following flags support section specifications:
-sectcreate segname sectname file
The section sectname in the segment segname is cre-
ated from the contents of file. The combination of
segname and sectname must be unique; there cannot
already be a section (segname,sectname) in any
input object file. This option was previously
called -segcreate, which will continue to be recog-
nized.
-sectalign segname sectname value
The section named sectname in the segment segname
will have its alignment set to value, where value
is a hexadecimal number that must be an integral
power of 2. This can be used to set the alignment
of a section created from a file, or to increase
the alignment of a section from an object file, or
to set the maximum alignment of the (__DATA,__com-
mon) section, where common symbols are defined by
the link editor. Setting the alignment of a lit-
eral section causes the individual literals to be
aligned on that boundary. If the section alignment
is not specified by a section header in an object
file or on the command line, it defaults to 10
(hex), indicating 16-byte alignment.
-sectorder segname sectname orderfile
The section sectname in the segment segname of the
input files will be broken up into blocks associ-
ated with symbols in the section. The output sec-
tion will be created by ordering the blocks as
specified by the lines in the orderfile. These
blocks are aligned to the output file's section
alignment for this section. Any section can be
ordered in the output file except symbol pointer
and symbol stub sections.
For non-literal sections, each line of the order-
file contains an object name and a symbol name,
separated by a single colon (':'). If the object
file is in an archive, the archive name, followed
by a single colon, must precede the object file
name. The object file names and archive names
should be exactly the names as seen by the link
editor, but if not, the link editor attempts to
match up the names the best it can. For non-lit-
eral sections, the easiest way to generate an order
file is with the ``-jonls +segname sectname''
options to nm(1).
The format of the orderfile for literal sections is
specific to each type of literal section. For C
string literal sections, each line of the order
file contains one literal C string, which may
include ANSI C escape sequences. For four-byte
literal sections, the order file format is one
32-bit hex number with a leading 0x per line, with
the rest of the line treated as a comment. For
eight-byte literal sections, the order file has two
32-bit hex numbers per line; each number has a
leading 0x, the two numbers are separated by white
space, and the rest of the line is treated as a
comment. For literal pointer sections, the lines
in the order file represent pointers, one per line.
A literal pointer is represented by the name of the
segment that contains the literal being pointed to,
followed by the section name, followed by the lit-
eral. These three strings are separated by colons
with no extra white space. For all the literal
sections, each line in the the order file is simply
entered into the literal section and will appear in
the output file in the same order as in the order
file. There is no check to see whether the literal
is present in the loaded objects. For literal sec-
tions, the easiest way to generate an order file is
with the ``-X -v -s segname sectname'' options to
otool(1).
-sectorder_detail
When using the -sectorder option, any pairs of
object file names and symbol names that are found
in the loaded objects, but not specified in the
orderfile, are placed last in the output file's
section. These pairs are ordered by object file
(as the filenames appear on the command line), with
the different symbols from a given object file
being ordered by increasing symbol address (that
is, the order in which the symbols occurred in the
object file, not their order in the symbol table).
By default, the link editor displays a summary that
simply shows the number of symbol names found in
the loaded objects but not in the orderfile, as
well as the number of symbol names listed in the
orderfile but not found in the loaded objects.
(The summary is omitted if both values are zero.)
To instead produce a detailed list of these sym-
bols, use the -sectorder_detail flag. If an object
file-symbol name pair is listed multiple times, a
warning is generated, and the first occurrence is
used.
-sectobjectsymbols segname sectname
This causes the link editor to generate local sym-
bols in the section sectname in the segment seg-
name. Each object file that has one of these sec-
tions will have a local symbol created whose name
is that of the object file, or of the member of the
archive. The symbol's value will be the first
address where that object file's section was
loaded. The symbol has the type N_SECT and its
section number is the the same as that of the sec-
tion (segname,sectname) in the output file. This
symbol will placed in the symbol table just before
all other local symbols for the object file. This
feature is typically used where the section is
(__TEXT,__text), in order to help the debugger
debug object files produced by old versions of the
compiler or by non-Apple compilers.
The following flags are related to name spaces:
-twolevel_namespace
Specifies the output to be built as a two-level
namespace image. This option can also be specified
by setting the environment variable
LD_TWOLEVEL_NAMESPACE. This is the default.
-flat_namespace
Specifies the output to be built as a flat names-
pace image. This is not the default (but was the
default in MacOS X 10.0).
-force_flat_namespace
Specifies the executable output to be built and
executed treating all its dynamic libraries as flat
namespace images. This marks the executable so
that the dynamic link editor know to treat all
dynamic libraries as flat namespace images when the
program is executed.
-bundle_loader executable
This specifies the executable that will be loading
the bundle output file being linked. Undefined
symbols from the bundle are checked against the
specified executable like it was one of the dynamic
libraries the bundle was linked with. If the bun-
dle being created with -twolevel_namespace in
effect then the searching of the executable for
symbols is based on the placement of the -bun-
dle_loader flag relative to the dynamic libraries.
If the the bundle being created with -flat_names-
pace then the searching of the executable is done
before all dynamic libraries.
-private_bundle
This allows symbols defined in the output to also
be defined in executable in the -bundle_loader
argument when -flat_namespace is in effect. This
implies that the bundle output file being created
is going to be loaded by the executable with the
NSLINKMODULE_OPTION_PRIVATE option to NSLinkMod-
ule(3).
-twolevel_namespace_hints
Specifies to create the output with the two-level
namespace hints table to be used by the dynamic
linker. This is the default except when the -bun-
dle flag is specified. If this is used when the
-bundle flag is specified the bundle will fail to
load on a MacOS X 10.0 system with a malformed
object error.
NSLINKMODULE_OPTION_PRIVATE option to NSLinkMod-
ule(3) and that the symbols in the executable are
not to cause multiply defined symbol errors.
-multiply_defined treatment
Specifies how multiply defined symbols in dynamic
libraries when -twolevel_namespace is in effect are
to be treated. treatment can be: error, warning,
or suppress. Which cause the treatment of multiply
defined symbols in dynamic libraries as either,
errors, warnings, or suppresses the checking of
multiply symbols from dynamic libraries when
-twolevel_namespace is in effect. The default is
to treat multiply defined symbols in dynamic
libraries as warnings when -twolevel_namespace is
in effect.
-multiply_defined_unused treatment
Specifies how unused multiply defined symbols in
dynamic libraries when -twolevel_namespace is in
effect are to be treated. An unused multiply
defined symbol is one when there is a symbol
defined in the output that is also defined in the
dynamic libraries the output is linked with but the
symbol in the dynamic library is not used by any
reference in the output. treatment can be: error,
warning, or suppress. The default for unused mul-
tiply defined symbols is to suppress these mes-
sages.
-nomultidefs
specifying this flag marks the umbrella being cre-
ated such that the dynamic linker is guaranteed
that no multiple definitions of symbols in the
umbrella's sub-images will ever exist. This allows
the dynamic linker to always use the two-level
namespace lookup hints even if the timestamps of
the sub-images do not match. This flag implies
-multiply_defined error.
The following flags are related to symbols. These flags'
arguments are external symbols whose names have `_'
prepended to the C, FORTRAN, or Pascal variable name.
-ysym Display each file in which sym appears, its type,
and whether the file defines or references it. Any
multiply defined symbols are automatically traced.
Like most of the other symbol-related flags, -y
takes only one argument; the flag may be specified
more than once in the command line to trace more
than one symbol.
-Y number
For the first number undefined symbols, displays
each file in which the symbol appears, its type and
whether the file defines or references it (that is,
the same style of output produced by the -y
option). To keep the output manageable, this option
displays at most number references.
-keep_private_externs
Don't turn private external symbols into static
symbols, but rather leave them as private external
in the resulting output file.
-m Don't treat multiply defined symbols from the
linked objects as a hard error; instead, simply
print a warning. The first linked object defining
such a symbol is used for linking; its value is
used for the symbol in the symbol table. The code
and data for all such symbols are copied into the
output. The duplicate symbols other than the first
symbol may still end up being used in the resulting
output file through local references. This can
still produce a resulting output file that is in
error. This flag's use is strongly discouraged!
-whyload
Indicate why each member of a library is loaded.
In other words, indicate which currently undefined
symbol is being resolved, causing that member to be
loaded. This in combination with the above -ysym
flag can help determine exactly why a link edit is
failing due to multiply defined symbols.
-u sym Enter the argument sym into the symbol table as an
undefined symbol. This is useful for loading
wholly from a library, since initially the symbol
table is empty and an unresolved reference is
needed to force the loading of the first object
file.
-e sym The argument sym is taken to be the symbol name of
the entry point of the resulting file. By default,
the entry point is the address of the first section
in the first segment.
-idefinition:indirect
Create an indirect symbol for the symbol name defi-
nition which is defined to be the same as the sym-
bol name indirect (which is taken to be undefined).
When a definition of the symbol named indirect is
linked, both symbols will take on the defined type
and value.
This option overlaps with a compiler option. If
you use the compiler driver cc(1) to invoke ld,
invoke this option in this way: -Wl,-idefini-
tion:indirect.
-undefined treatment
Specifies how undefined symbols are to be treated.
treatment can be: error, warning, or suppress.
Which cause the treatment of undefined symbols as
either, errors, warnings, or suppresses the check-
ing of undefined symbols. The default is to treat
undefined symbols as errors.
-U sym Allow the symbol sym to be undefined, even if the
-r flag is not given. Produce an executable file
if the only undefined symbols are those specified
with -U.
This option overlaps with a compiler option. If
you use the compiler driver cc(1) to invoke ld,
invoke this option in this way: -Wl,-U,sym.
-bind_at_load
Causes the output file to be marked such that the
dynamic linker will bind all undefined references
when the file is loaded or launched.
The following flags are related to stripping link edit
information. This information can also be removed by
strip(1), which uses the same options. (The exception is
the -s flag below, but this is the same as strip(1) with
no arguments.) The following flags are listed in decreas-
ing level of stripping.
-s Completely strip the output; that is, remove the
symbol table and relocation information.
-x Strips the non-global symbols; only saves external
symbols.
This option overlaps with a compiler option. If
you use the compiler driver cc(1) to invoke ld,
invoke this option in this way: -Wl,-x.
-S Strip debugging symbols; only save local and global
symbols.
-X Strip local symbols whose names begin with `L';
save all other symbols. (The compiler and assem-
bler currently strip these internally-generated
labels by default, so they generally do not appear
in object files seen by the link editor.)
-Si Strip duplicate debugging symbols from include
files. This is the default.
-b Strip the base file's symbols from the output file.
(The base file is given as the argument to the -A
option.)
This option overlaps with a compiler option. If
you use the compiler driver cc(1) to invoke ld,
invoke this option in this way: -Wl,-b.
-Sn Don't strip any symbols.
-exported_symbols_list filename
The specified filename contains lists of global
symbol names that will remain as global symbols in
the output file. All other global symbols will be
treated as if they were marked as __pri-
vate_extern__ and will not be global in the output
file. The symbol names listed in filename must be
one per line. Leading and trailing white space are
not part of the symbol name. Lines starting with #
are ignored, as are lines with only white space.
-unexported_symbols_list filename
The specified filename contains lists of global
symbol names that will not remain as global symbols
in the output file. The symbols will be treated as
if they were marked as __private_extern__ and will
not be global in the output file. The symbol names
listed in filename must be one per line. Leading
and trailing white space are not part of the symbol
name. Lines starting with # are ignored, as are
lines with only white space.
The remaining options are infrequently used:
-w Suppresses all warning messages.
-no_arch_warnings
Suppresses warning messages about files that have
the wrong architecture for the -arch flag.
-arch_errors_fatal
Cause the errors having to do with files that have
the wrong architecture to be fatal and stop the
link editor.
-M Produce a load map, listing all the segments and
sections. The list includes the address where each
input file's section appears in the output file, as
well as the section's size.
This option overlaps with a compiler option. If
you use the compiler driver cc(1) to invoke ld,
invoke this option in this way: -Wl,-M.
-whatsloaded
Display a single line listing each object file that
is loaded. Names of objects in archives have the
form libfoo.a(bar.o).
-filelist listfile[,dirname]
Specifies that the linker should link the files
listed in listfile . This is an alternative to
listing the files on the command line. The file
names are listed one per line separated only by
newlines. (Spaces and tabs are assumed to be part
of the file name.) If the optional directory name,
dirname is specified, it is prepended to each name
in the list file.
-headerpad value
Specifies the minimum amount of space ("padding")
following the headers for the MH_EXECUTE format and
all output file types with the dynamic linker.
value is a hexadecimal number. When a segment's
size is rounded up to the segment alignment, there
is extra space left over, which is placed between
the headers and the sections, rather than at the
end of the segment. The headerpad option specifies
the minimum size of this padding, which can be use-
ful if the headers will be altered later. The
default value is the 2 * sizeof(struct section) so
the program /usr/bin/objcunique can always add two
section headers. The actual amount of pad will be
as large as the amount of the first segment's
round-off. (That is, take the total size of the
first segments' headers and non-zerofill sections,
round this size up to the segment alignment, and
use the difference between the rounded and
unrounded sizes as the minimum amount of padding.)
-headerpad_max_install_names
Add to the header padding enough space to allow
changing all dynamic shared library paths recorded
in the output file to be changed to MAXPATHLEN in
length.
-t Trace the progress of the link editor; display the
name of each file that is loaded as it is processed
in the first and second pass of the link editor.
-A basefile
Incremental loading: linking is to be done in a
manner that lets the resulting object be read into
an already executing program, the basefile. base-
file is the name of a file whose symbol table will
be taken as a basis on which to define additional
symbols. Only newly linked material will be
entered into the a.out file, but the new symbol
table will reflect every symbol defined in the base
file and the newly linked files. Option(s) to
specify the addresses of the segments are typically
needed, since the default addresses tend to overlap
with the basefile. The default format of the
object file is MH_OBJECT. Note: It is strongly
recommended that this option NOT be used, because
the dyld package described in dyld(3) is a much
easier alternative.
-dylib_install_name name
For dynamic shared library files, specifies the
name of the file the library will be installed in
for programs that use it. If this is not speci-
fied, the name specified in the -o name option will
be used. This option is used as the libtool(1)
-install_name name option when its -dynamic option
is specified.
-umbrella framework_name
Specifies this is a subframework where frame-
work_name is the name of the umbrella framework
this subframework is a part of. Where frame-
work_name is the same as the argument to the
-framework framework_name option. This subframe-
work can then only be linked into the umbrella
framework with the same framework_name or another
subframework with the same umbrella framework name.
Any other attempt to statically link this subframe-
work directly will result in an error stating to
link with the umbrella framework instead. When
building the umbrella framework that uses this sub-
framework no additional options are required. How-
ever the install name of the umbrella framework,
required to be specified with -dylib_install_name,
must have the proper format for an install name of
a framework for the framework_name of the umbrella
framework to be determined.
-allowable_client client_name
Specifies that for this subframework the
client_name can link with this subframework without
error even though it is not part of the umbrella
framework that this subframework is part of. The
client_name can be another framework name or a name
used by bundles (see the -client_name client_name
option below).
-client_name client_name
Specifies the client_name of a bundle for checking
of allowable clients of subframeworks (see the
-allowable_client client_name option above).
-sub_umbrella framework_name
Specifies that the framework_name being linked by a
dynamic library is to be treated as it one of the
subframeworks with respect to twolevel namespace.
-sub_library library_name
Specifies that the library_name being linked by a
dynamic library is to be treated as it one of the
sublibraries with respect to twolevel namespace.
For example the library_name for
/usr/lib/libobjc_profile.A.dylib would be libobjc.
-init sym
The argument sym is taken to be the symbol name of
the dynamic shared library initialization routine.
If any module is used from the dynamic library the
library initialization routine is called before any
symbol is used from the library including C++
static initializers (and #pragma CALL_ON_LOAD rou-
tines).
-run_init_lazily
This option is obsolete.
-dylib_compatibility_version number
For dynamic shared library files, this specifies
the compatibility version number of the library.
When a library is used by a program, the compati-
bility version is checked and if the program's ver-
sion is greater that the library's version, it is
an error. The format of number is X[.Y[.Z]] where
X must be a positive non-zero number less than or
equal to 65535, and .Y and .Z are optional and if
present must be non-negative numbers less than or
equal to 255. If the compatibility version number
is not specified, it has a value of 0 and no check-
ing is done when the library is used. This option
is used as the libtool(1) -compatibility_version
number option when its -dynamic option is set.
-dylib_current_version number
For dynamic shared library files, specifies the
current version number of the library. The current
version of the library can be obtained programmati-
cally by the user of the library so it can deter-
mine exactly which version of the library it is
using. The format of number is X[.Y[.Z]] where X
must be a positive non-zero number less than or
equal to 65535, and .Y and .Z are optional and if
present must be non-negative numbers less than or
equal to 255. If the version number is not speci-
fied, it has a value of 0. This option is used as
the libtool(1) -current_version number option when
its -dynamic option is set.
-single_module
When building a dynamic library build the library
so that it contains only one module.
-multi_module
When building a dynamic library build the library
so that it contains one module for each object file
linked in. This is the default.
-dylinker_install_name name
For dynamic link editor files, specifies the name
of the file the dynamic link editor will be
installed in for programs that use it.
The following environment variable is used to control the
use of incompatible features in the output with respect to
Mac OS X releases.
MACOSX_DEPLOYMENT_TARGET
This is set to indicate the oldest Mac OS X version
that that the output is to be used on. When this
is set to a release that is older that the current
release features that are incompatible with that
release will be disabled. If a feature is seen in
the input that can't be in the output due to this
setting a warning is issued. The current allowable
values for this are 10.1 and 10.2 with the default
being 10.1.
The following environment variables are used by Apple's
Build and Integration team:
RC_TRACE_ARCHIVES
When this is set it causes a message of the form
``[Logging for Build & Integration] Used static
archive: filename'' for each static archive that
has members linked into the output.
RC_TRACE_DYLIBS
When this is set it causes a message of the form
``[Logging for Build & Integration] Used dynamic
library: filename'' for each dynamic library linked
into the output.
RC_TRACE_PREBINDING_DISABLED
When this is set it causes a message of the form
``[Logging for Build & Integration] prebinding dis-
abled for filename because reason''. Where file-
name is the value of the -final_output argument if
specified or the value of the -o argument.
-final_output filename
The argument filename is used in the above message
when RC_TRACE_PREBINDING_DISABLED is set.
Options available in early versions of the Mach-O link
editor may no longer be supported.
FILES
/lib/lib*.{a,dylib} libraries
/usr/lib/lib*.{a,dylib}
/usr/local/lib/lib*.{a,dylib}
/Library/Frameworks/*.framework/* framework
libraries
/Network/Library/Frameworks/*.framework/* framework
libraries
/System/Library/Frameworks/*.framework/* framework
libraries
a.out output file
SEE ALSO
as(1), ar(1), cc(1), libtool(1), ranlib(1), atom(1),
nm(1), otool(1) lipo(1), arch(3), dyld(3), Mach-O(5),
strip(1), redo_prebinding(1)
Apple Computer, Inc. October 28, 2002 LD(1)