Manual Pages for UNIX Darwin command on man ld

Manual Pages for UNIX Darwin command on man ld_classic

LDCLASSIC(1) LDCLASSIC(1)

NAME

ldclassic - The old Mach object file link editor

SYNOPSIS

llddccllaassssiicc [ option ... ] [ file ... ]

DESCRIPTION

The ldclassic 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 ldclassic combines them, producing an object file which can either be executed or become

the input for a further ldclassic run. (In the latter case, the -rr

option must be given to preserve the relocation information.) Unless an output file is specified, ldclassic produces a file named aa..oouutt. This file is made executable only if no errors occurred during the link editing and there are no undefined symbols. UUNNIIVVEERRSSAALL FFIILLEE SSUUPPPPOORRTT

The link editor accepts ``universal'' (multiple-architecture) input

files, but always creates a ``thin'' (single-architecture), standard

Mach-O output file. The architecture is specified using the -aarrcchh

archtype option. If this option is not used, ldclassic(1) attempts to determine the output architecture by examining the first object file

encountered on the command line. If it is a ``thin'' file, its archi-

tecture determines that of the output file. If the first input file is a ``universal'' file, the ``best'' architecture for the host is used.

(See the explanation of the -aarrcchh option, below.)

The compiler driver cc(1) handles creating universal executables by calling ldclassic(1) multiple times and using lipo(1) to create a ``universal'' file from the results of the ldclassic(1) executions. OOUUTTPPUUTT FFIILLEE LLAAYYOOUUTT The object files are loaded in the order in which they are specified on the command line. The segments and the sections 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 -sseeccttccrreeaattee 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 coming 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 sections for that segment.

If the option -sseegglliinnkkeeddiitt is specified, the segment it creates is the

last segment in the output file.

The address of each segment can be specified with -sseeggaaddddrr,, which takes

the segment's name as an argument. The address of the first segment

can alternatively be specified using -sseegg11aaddddrr,, 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 segment. If the address of the first segment has not been specified by name, its assigned address will be the specified (via

-sseegg11aaddddrr) 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 (MHEXECUTE), in

which case the default first address is the value of the segment align-

ment.

For demand-paged executable format (MHEXECUTE) 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 cre-

ated 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 sec-

tion in the first segment (unless the -ee option is specified).

SSTTAATTIICC AARRCCHHIIVVEE LLIIBBRRAARRIIEESS ldclassic supports two types of libraries: static archive libraries

and dynamic shared libraries. Searching for undefined symbols is per-

formed 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 ldclas-

sic, it is searched exactly once, at the point it is encountered in the

argument list. Only those members defining an unresolved external ref-

erence, 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 editing using the -ss 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 con-

tents iteratively, loading members until no further references are sat-

isfied. In the unsorted case, the first member of the static archive library is named ``.SYMDEF'', which is understood to be a table of contents in the order of the archive members. Static archive library members can also be loaded in response to the

-OObbjjCC and -aallllllooaadd flags. See their descriptions below.

DDYYNNAAMMIICC SSHHAARREEDD LLIIBBRRAARRIIEESS When a dynamic shared library or an object file that was linked against a dynamic shared library is specified as an argument to ldclassic, 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. When linking -flatnamespace, all

dynamic 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 editor checks for undefined symbols by simulating the way the dynamic linker will search for undefined symbols at runtime. 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 symbol, 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 unde-

fined 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 symbol. Different link-

ing 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 undefined 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. Search-

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

TWOLEVEL 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 pro-

gram 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 an 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 defi-

nition (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 bundles 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 an output file with the static link editor when

-ttwwoolleevveellnnaammeessppaaccee is in effect (now the default) all undefined refer-

ences must be satisfied at static link time. The flags to allow unde-

fined references, -UUsymbolname, -uunnddeeffiinneedd warning and -uunnddeeffiinneedd sup-

press can't be used. When the environment variable MMAACCOOSSXXDDEEPPLLOOYY-

MMEENNTTTTAARRGGEETT is set to 1100..33 or higher then -uunnddeeffiinneedd dynamiclookup can

also be used. The specific library definition recorded for each refer-

ence 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 frame-

work's sub-frameworks, sub-umbrellas and sub-libraries for those refer-

ences. 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. When creating bundles (MHBUNDLE 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 -bbuunnddlleellooaaddeerr exe-

cutable must be used. When creating an output file with the static link editor when

-ffllaattnnaammeessppaaccee is in effect (the MacOS X 10.0 default) all

undefined references must be satisfied at static link time when

-uunnddeeffiinneedd error (the default) is used. The static link editor

checks the undefined references by searching all the libraries

listed on the link line then all dependent libraries. The unde-

fined symbols in the created output file are left to be resolved at execution time by the dynamic link editor in the dynamic libraries in the search order of the program. MMUULLTTIIPPLLYY DDEEFFIINNEEDD SSYYMMBBOOLLSS 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 namespace 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 -mmuullttiippllyyddeeffiinneedd

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

ates a multiply defined symbol warning (by default), where the treat-

ment of this warning can be changed with the -mmuullttiippllyyddeeffiinneedd flag.

UUSSIINNGG TTHHEE DDYYNNAAMMIICC LLIINNKK EEDDIITTOORR AANNDD DDYYNNAAMMIICC SSHHAARREEDD LLIIBBRRAARRIIEESS

The option -ddyynnaammiicc 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 -ssttaattiicc

can be specified. Only one of these flags can be specified. LLIINNKK EEDDIITTOORR DDEEFFIINNEEDD SSYYMMBBOOLLSS There is a group of link editor defined symbols for the MHEXECUTE,

MHDYLIB and MHPRELOAD file types (see the header file 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 sym-

bols that are referenced by the object file appear in the output file's symbol table.

The link editor defined symbol `mhexecuteheader' (`mhexe-

cuteheader' in C) is reserved when the output file format is MHEXE-

CUTE. This symbol is the address of the Mach header in a Mach-O exe-

cutable (a file of type MHEXECUTE). 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 `mhdylibheader' (`mhdylibheader' in C) is reserved when the output file format is MHDYLIB. This symbol

is the address of the Mach header in a Mach-O dynamic shared library (a

file of type MHDYLIB) 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, however, must have the value dyldgetimagevmaddrslide(3) added to them.

The MHPRELOAD file type has link editor defined symbols for the begin-

ning 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 segment's

beginning and end have the form: SEGNAMEbegin and SEGNAMEend,

where SEGNAME is the name of the segment. Similarly, the symbols for

a section have the form: SEGNAMEsectnamebegin and SEG-

NAMEsectnameend, 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 symbol's type is still that of the section mentioned in the symbol's name.) OOPPTTIIOONNSS Ld understands several options. Filenames and options that refer to

libraries (such as -ll and -ffrraammeewwoorrkk), as well as options that create

symbols (such as -uu and -ii), are position-dependent: They define the

load order and affect what gets loaded from libraries. Some ldclassic options overlap with compiler options. If the compiler driver cc(1) is

used to invoke ldclassic , it maybe necessary to pass the ldclas-

sic(1) options to cc(1) using -WWll,,-ooppttiioonn,,aarrgguummeenntt11,,aarrgguummeenntt22.

In this release of the static link editor, 64-bit code is processed by

a the new link editor /usr/bin/ld. And it is an error to pass -arch

ppc64 or -arch x8664 to ldclassic(1).

The most common option is:

-oo name

The output file is named name, instead of aa..oouutt. The following flags are related to architectures:

-aarrcchh archtype

Specifies the architecture, archtype, for the output file. ``Universal'' input files that do not contain this specified

architecture are ignored. Only one -aarrcchh archtype can be spec-

ified. See arch(3) for the currently known archtypes. If archtype specifies a certain implementation of an architecture

(such as -aarrcchh m68040 or -aarrcchh i486 ), the resulting object file

has that specific CPU subtype, and it is an error if any input file has a CPU subtype that will not combine to the CPU subtype for archtype. 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 ``universal'' file that contains only one architec-

ture, the output file will have the same architecture. Other-

wise, if it is a ``universal'' 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 -aarrcchh archtype must be speci-

fied. For family architectures (like ppc and i386) the CPU sub-

type of the linked output is the ALL cpusubtype. For specific CPU subtypes (ppc7400 vs. ppc970), the resulting CPU subtype of

the linked output is to 'combine' the CPU subtypes. The combin-

ing is CPU specific and generally results in the minimum CPU subtype needed to support all the combined CPU subtypes.

-aarrcchhmmuullttiippllee

This flag is used by the cc(1) driver program when it is run

with multiple -aarrcchh archtype flags. It instructs programs like

ldclassic(1) to precede any displayed message with a line stat-

ing the program name, in this case ldclassic, and the architec-

ture (from the -aarrcchh archtype flag). This helps distinguish

which architecture the error messages refer to.

-ffoorrcceeccppuussuubbttyyppeeAALLLL

The -ffoorrcceeccppuussuubbttyyppeeAALLLL flag causes the CPU subtype to remain

the ALL CPU subtype and not to be combined or changed. This

flag has precedence over any -aarrcchh archtype flag for a specific

implementation. This is the default for all x86 architectures. 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):

-ddyynnaammiicc

Allows use of the features associated with dynamic link editor.

The default is -ddyynnaammiicc..

-ssttaattiicc

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 -ssttaattiicc are

marked with the statement "when -ddyynnaammiicc

is used").

-rreeaaddoonnllyyrreellooccss treatment

Specifies how relocation entries in read-only sections are to be

treated when -ddyynnaammiicc is used. To get the best possible shar-

ing, the read-only sections 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 -ddyynnaammiicc.. But in

such cases non-converted assembly code or objects not compiled

with -ddyynnaammiicc relocation entries will appear in read-only sec-

tions. The treatment can be: error, warning, 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.

-sseeccttddiiffffrreellooccss treatment

Specifies how section difference relocation enries are to be

treated when -ddyynnaammiicc and -eexxeeccuuttee are used. To get the best

possible code generation the compiler should not generate code

for executables (MHEXECUTE format outputs) that have any sec-

tion difference relocation entries. The gcc(1) compiler has the

-mmddyynnaammiicc-nnoo-ppiicc flag for generating code for executables. The

default treatment is suppress, where no message is printed. The other treatments are error or warning. This option can also be specified by setting the environment variable LDSECTDIFFRELOCS to the treatment values.

-wweeaakkrreeffeerreenncceemmiissmmaattcchheess treatment

Specifies how to treat mismatches of symbol references in the the object files being linked. Normally 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 references. The

default treatment is error, where the link fails with an error

message. The other treatments are weak or non-weak, which makes

mismatched undefined symbol references either weak or non-weak

in the output, respectively. 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.

-pprreebbiinndd

Have the static linker, ldclassic(1), prebind an executable's or dynamic shared library's undefined symbols to the addresses

of the dynamic libraries it is being linked with. This opti-

mization 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 pro-

gram was linked, the dynamic linker can use the prebound addresses. If not, the dynamic linker undoes the prebinding and binds normally. This option can also be specified by setting

the environment variable LDPREBIND. If the environment vari-

able LDFORCENOPREBIND is set both the option -pprreebbiinndd LDPRE-

BIND environment variable are ignore and the output is not pre-

bound. Or if the environment variable MMAACCOOSSXXDDEEPPLLOOYYMMEENNTTTTAARRGGEETT is set to 10.4 or greater and the output is not a split a dynamic library the output is not prebound.

-nnoopprreebbiinndd

Do not have the static linker, ldclassic(1), prebind the out-

put. If this is specified the environment variable LDPREBIND is ignored.

-pprreebbiinnddaalllloowwoovveerrllaapp

Have the static linker, ldclassic(1), prebind the output even if the addresses of the dynamic libraries it uses overlap. The resulting output can then have redoprebinding(1) run on it to fix up the prebinding after the overlapping dynamic libraries have been rebuilt. This option can also be specified by setting the environment variable LDPREBINDALLOWOVERLAP.

-pprreebbiinnddaallllttwwoolleevveellmmoodduulleess

Have the static linker, ldclassic(1), mark all modules from

prebound two-level namespace dynamic libraries as used by the

program even if they are not statically referenced. This can

provide improved launch time for programs like Objective-C pro-

grams that use symbols indirectly through NIB files. This option can also be specified by setting the environment variable LDPREBINDALLTWOLEVELMODULES.

-nnoopprreebbiinnddaallllttwwoolleevveellmmoodduulleess

Don't have the static linker, ldclassic(1), mark all modules

from prebound two-level namespace dynamic libraries as used by

the program. This flag overrides the setting of the environment variable LDPREBINDALLTWOLEVELMODULES.

-nnooffiixxpprreebbiinnddiinngg

Have the static linker, ldclassic(1), mark the executable so that the dynamic linker will never notify the prebinding agent if this launched and its prebinding is out of date. This is used when building the prebinding agent itself. The following flags are related to libraries:

-llx This option is an abbreviation for the library name `libx.a',

where x is a string. If -ddyynnaammiicc is specified the abbreviation

for the library name is first search as `libx.dylib' and then `libx.a' is searched for. ldclassic searches for libraries

first in any directories specified with -LL options, then in any

directories specified in the colon separated set of paths in the

environment variable LDLIBRARYPATH, then the standard directo-

ries //lliibb, //uussrr//lliibb, and //uussrr//llooccaall//lliibb. A library is searched

when its name is encountered, so the placement of the -ll 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.

-wweeaakk-llx

This is the same as the -llx but forces the library and all ref-

erences to it to be marked as weak imports. Care must be taken

when using this as the use of the non-weak symbol references in

an object file may cause the program to crash when the symbol or library is not present at execution time.

-wweeaakklliibbrraarryy filenamepathtolibrary

This is the same as listing a file name path to a library on the link line except that it forces the library and all references to it to be marked as weak imports. Care must be taken when

using this as the use of the non-weak symbol references in an

object file may cause the program to crash when the symbol or library is not present at execution time.

-LLdir Add dir to the list of directories in which to search for

libraries. Directories specified with -LL are searched before

the standard directories.

-ZZ Do not search the standard directories when searching for

libraries.

-ssyysslliibbrroooott rootdir

Prepend rootdir to the standard directories when searching for libraries or frameworks.

-sseeaarrcchhppaatthhssffiirrsstt

By default when the -ddyynnaammiicc flag is in effect, the -llx and

-wweeaakk-llx options first search for a file of the form

`libx.dylib' in each directory in the library search path, then a file of the form `libx.a' is searched for in the library search paths. This option changes it so that in each path `libx.dylib' is searched for then `libx.a' before the next path in the library search path is searched.

-ffrraammeewwoorrkk 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 specified, ldclassic searches for framework `name.frame-

work/name' first in any directories specified with the -FF

option, then in the standard framework directories

//LLiibbrraarryy//FFrraammeewwoorrkkss, //NNeettwwoorrkk//LLiibbrraarryy//FFrraammeewwoorrkkss, and //SSyyss-

tteemm//LLiibbrraarryy//FFrraammeewwoorrkkss. The placement of the -ffrraammeewwoorrkk 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.

-wweeaakkffrraammeewwoorrkk name[,suffix]

This is the same as the -ffrraammeewwoorrkk name[,suffix] but forces the

framework and all references to it to be marked as weak imports.

Care must be taken when using this as the use of the non-weak

symbol references in an object file may cause the program to crash when the symbol or framework is not present at execution time.

-FFdir Add dir to the list of directories in which to search for frame-

works. Directories specified with -FF are searched before the

standard framework directories.

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

-aallllllooaadd

Loads all members of static archive libraries. This option does not apply to dynamic shared libraries.

-ddyylliibbffiillee installname:filename

Specifies that a dynamic shared library is in a different loca-

tion 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 loca-

tion. installname specifies the path where the library nor-

mally resides. filename 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:

-ddyylliibbffiillee //lliibb//lliibbssyyssss..AA..ddyylliibb:://mmee//lliibb//lliibbssyyssss..AA..ddyylliibb.

-eexxeeccuuttaabblleeppaatthh pathname

Specifies that pathname is used to replace @executablepath for dependent libraries. The following options specify the output file format (the file type):

-eexxeeccuuttee

Produce a Mach-O demand-paged executable format file. The head-

ers are placed in the first segment, and all segments are padded to the segment alignment. This has a file type of MHEXECUTE. This is the default. If no segment address is specified at address zero, a segment with no protection (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 -MMaacchh, which

will continue to be recognized.

-oobbjjeecctt

Produce a Mach-O file in the relocatable object file format that

is intended for execution. This differs from using the -rr

option in that it defines common symbols, does not allow unde-

fined symbols and does not preserve relocation entries. This has a file type of MHOBJECT. In this format all sections are placed in one unnamed segment with all protections (read, write, execute) allowed on that segment. This is intended for extremely small programs that would otherwise be large due to

segment padding. In this format, and all non-MHEXECUTE for-

mats, the link editor defined symbol ``mhexecuteheader'' is not defined since the headers are not part of the segment. This format file can't be used with the dynamic linker.

-pprreellooaadd

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 MHPRELOAD. This option was previously

-pp, which will continue to be recognized.

-ddyylliibb 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 seg-

ment alignment. This has a file type of MHDYLIB. This option

is used by libtool(1) when its -ddyynnaammiicc option is specified.

-bbuunnddllee

Produce a Mach-O bundle format file. The headers are placed in

the first segment. All sections are placed in their proper seg-

ments and they are padded to the segment alignment. This has a file type of MHBUNDLE.

-ddyylliinnkkeerr

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

ment. This has a file type of MHDYLINKER.

-ffvvmmlliibb

Produce a Mach-O fixed VM shared library format file. The head-

ers are placed in the first segment but the first section in

that segment will be placed on the next segment alignment bound-

ary 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 MHFVMLIB. The following flags affect the contents of the output file:

-rr Save the relocation information in the output file so that it

can be the subject of another ldclassic run. The resulting

file type is a Mach-O relocatable file (MHOBJECT) if not other-

wise specified. This flag also prevents final definitions from being given to common symbols, and suppresses the `undefined symbol' diagnostics.

-dd Force definition of common storage even if the -rr 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 -rr is not specified.

The following flags support segment specifications:

-sseeggaalliiggnn value

Specifies the segment alignment. value is a hexadecimal number that must be an integral power of 2. The default is the target pagesize (currently 1000 hex for the PowerPC and i386).

-sseegg11aaddddrr addr

Specifies the starting address of the first segment in the out-

put file. addr is a hexadecimal number and must be a multiple of the segment alignment. This option can also be specified as

-iimmaaggeebbaassee..

-sseeggaaddddrr name addr

Specifies the starting address of the segment named name to be

addr. The address must be a hexadecimal number that is a multi-

ple of the segment alignment.

-sseeggssrreeaaddoonnllyyaaddddrr 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 number and must be a multiple of the segment alignment.

-sseeggssrreeaaddwwrriitteeaaddddrr addr

Specifies the starting address of the read-write segments in a

dynamic shared library. When this option is used the

-sseeggssrreeaaddoonnllyyaaddddrr must also be used (see above). addr is a

hexadecimal number and must be a multiple of the segment align-

ment.

-sseeggaaddddrrttaabbllee filename

For dynamic shared libraries the -sseegg11aaddddrr or the pair of

-sseeggssrreeaaddoonnllyyaaddddrr and -sseeggssrreeaaddwwrriitteeaaddddrr 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 -sseegg11aaddddrr .. In the second

form the first address is used as the -sseeggssrreeaaddoonnllyyaaddddrr

address and the second address is used as the

-sseeggssrreeaaddwwrriitteeaaddddrr address. This option can also be speci-

fied by setting the environment variable LDSEGADDRTABLE. If

the environment variable is set then any -sseegg11aaddddrr,

-sseeggssrreeaaddoonnllyyaaddddrr, -sseeggssrreeaaddwwrriitteeaaddddrr and -sseeggaaddddrrttaabbllee

options are ignored and a warning is printed.

-sseeggaaddddrrttaabblleeffiilleennaammee pathname

Use ppaatthhnnaammee instead of the install name of the library for matching an entry in the segment address table.

-sseeggpprroott name max init

Specifies the maximum and initial virtual memory protection of the named segment, name, to be max and init ,respectively. 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 for PowerPC architecures and `rw` for the all Intel architecures. 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' (and for Intel architecures it also sets the maximum protection to `rwx' in this case). The default for the initial protection for the ``TEXT'' segment is `rx' (not writable).

-sseegglliinnkkeeddiitt

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 output file type is not MHOBJECT and MHPRELOAD output 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 `mhexecuteheader' (see

Mach-O(5)).

-nnoosseegglliinnkkeeddiitt

Do not create the link edit segment (see -sseegglliinnkkeeddiitt above).

-ppaaggeezzeerroossiizzee 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 for i386).

-ssttaacckkaaddddrr 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 for i386). If -ssttaacckkssiizzee

is specified and -ssttaacckkaaddddrr is not, a default stack address

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

-ssttaacckkssiizzee 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 for i386). If -ssttaacckkaaddddrr

is specified and -ssttaacckkssiizzee is not, a default stack size spe-

cific for the architecture being linked will be used and its value printed as a warning message. This creates a segment named UNIXSTACK .

-aalllloowwssttaacckkeexxeeccuuttee

Marks executable so that all stacks in the task will be given stack execution privilege. This includes pthread stacks. The following flags support section specifications:

-sseeccttccrreeaattee segname sectname file

The section sectname in the segment segname is created 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

-sseeggccrreeaattee, which will continue to be recognized.

-sseeccttaalliiggnn 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 maxi-

mum alignment of the (DATA,common) section, where common symbols are defined by the link editor. Setting the alignment of a literal section causes the individual literals to be

aligned on that boundary. If the section alignment is not spec-

ified by a section header in an object file or on the command

line, it defaults to 10 (hex), indicating 16-byte alignment.

-sseeccttoorrddeerr segname sectname orderfile

The section sectname in the segment segname of the input files will be broken up into blocks associated with symbols in the section. The output section 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 sec-

tion. Any section can be ordered in the output file except sym-

bol pointer and symbol stub sections.

For non-literal sections, each line of the orderfile contains an

object name and a symbol name, separated by a single colon

(':'). Lines that start with # are ignored and treated as com-

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

sections, the easiest way to generate an order file is with the

``-jjoonnllss ++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 sec-

tions, 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 com-

ment. 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 literal. These three strings are separated

by colons with no extra white space. For all the literal sec-

tions, 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 lit-

eral sections, the easiest way to generate an order file is with

the ``-XX -vv -ss segname sectname'' options to otool(1).

-sseeccttoorrddeerrddeettaaiill

When using the -sseeccttoorrddeerr 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 sym-

bols 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 symbols, use the -sseeccttoorrddeerrddeettaaiill flag. If an

object file-symbol name pair is listed multiple times, a warning

is generated, and the first occurrence is used.

-sseeccttoobbjjeeccttssyymmbboollss segname sectname

This causes the link editor to generate local symbols in the section sectname in the segment segname. Each object file that has one of these sections will have a local symbol created whose

name is that of the object file, or of the member of the ar-

chive. The symbol's value will be the first address where that object file's section was loaded. The symbol has the type NSECT and its section number is the the same as that of the section (segname,sectname) in the output file. This symbol will

be placed in the symbol table just before all other local sym-

bols 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:

-ttwwoolleevveellnnaammeessppaaccee

Specifies the output to be built as a two-level namespace image.

This option can also be specified by setting the environment

variable LDTWOLEVELNAMESPACE. This is the default.

-ffllaattnnaammeessppaaccee

Specifies the output to be built as a flat namespace image. This is not the default (but was the default in MacOS X 10.0).

-ffoorrcceeffllaattnnaammeessppaaccee

Specifies the executable output to be built and executed treat-

ing all its dynamic libraries as flat namespace images. This marks the executable so that the dynamic link editor treats all dynamic libraries as flat namespace images when the program is executed.

-bbuunnddlleellooaaddeerr 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 bundle

being created with -ttwwoolleevveellnnaammeessppaaccee in effect then the

searching of the executable for symbols is based on the place-

ment of the -bbuunnddlleellooaaddeerr flag relative to the dynamic

libraries. If the the bundle being created with -ffllaattnnaammeessppaaccee

then the searching of the executable is done before all dynamic libraries.

-pprriivvaatteebbuunnddllee

This allows symbols defined in the output to also be defined in

executable in the -bbuunnddlleellooaaddeerr argument when -ffllaattnnaammeessppaaccee

is in effect. This implies that the bundle output file being created is going to be loaded by the executable with the NNSSLLIINNKKMMOODDUULLEEOOPPTTIIOONNPPRRIIVVAATTEE option to NSLinkModule(3).

-ttwwoolleevveellnnaammeessppaacceehhiinnttss

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 -bbuunnddllee flag is specified. If this is

used when the -bbuunnddllee flag is specified the bundle will fail to

load on a MacOS X 10.0 system with a malformed object error.

-mmuullttiippllyyddeeffiinneedd treatment

Specifies how multiply defined symbols in dynamic libraries when

-ttwwoolleevveellnnaammeessppaaccee 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 -ttwwoolleevveellnnaammeessppaaccee is in effect.

The default is to treat multiply defined symbols in dynamic

libraries as warnings when -ttwwoolleevveellnnaammeessppaaccee is in effect.

-mmuullttiippllyyddeeffiinneedduunnuusseedd treatment

Specifies how unused multiply defined symbols in dynamic

libraries when -ttwwoolleevveellnnaammeessppaaccee is in effect are to be

treated. An unused multiply defined symbol is one in which 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 out-

put. treatment can be: error, warning, or suppress. The default for unused multiply defined symbols is to suppress these messages.

-nnoommuullttiiddeeffss

specifying this flag marks the umbrella being created 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 -mmuullttiippllyyddeeffiinneedd 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.

-yysym 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, -yy takes only one argument; the flag may be specified

more than once in the command line to trace more than one sym-

bol.

-YY 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 -yy option). To keep the output manageable, this option dis-

plays at most number references.

-kkeeeepppprriivvaatteeeexxtteerrnnss

Don't turn private external symbols into static symbols, but rather leave them as private external in the resulting output file.

-mm 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 sym-

bols 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!

-wwhhyyllooaadd

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 -yysym flag can help determine exactly why a link

edit is failing due to multiply defined symbols.

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

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

-iidefinition:indirect

Create an indirect symbol for the symbol name definition which is defined to be the same as the symbol 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 ldclassic, invoke this option

in this way: -WWll,,-iidefinition:indirect.

-uunnddeeffiinneedd 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 checking of undefined symbols. The default is to treat undefined symbols as errors. When the environment variable

MMAACCOOSSXXDDEEPPLLOOYYMMEENNTTTTAARRGGEETT is set to 1100..33 or higher then -uunnddee-

ffiinneedd dynamiclookup can also be used to allow any undefined symbols to be looked up dynamically at runtime. Use of a binary built with this flag requires a system with a dynamic linker

from Mac OS X 10.3 or later. The flag -uunnddeeffiinneedd defineaway

can also be used to cause the static linker to create a private definition for all undefined symbols. This flag should only be

used if it is known that the undefined symbols are not refer-

enced as any use of them may cause a crash.

-UU sym Allow the symbol sym to be undefined, even if the -rr flag is not

given. Produce an executable file if the only undefined symbols

are those specified with -UU..

This option overlaps with a compiler option. If you use the compiler driver cc(1) to invoke ldclassic, invoke this option

in this way: -WWll,,-UU,,sym.

-bbiinnddaattllooaadd

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 -ss flag below, but this is the same as

strip(1) with no arguments.) The following flags are listed in decreasing level of stripping.

-ss Completely strip the output; that is, remove the symbol table

and relocation information.

-xx 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 ldclassic, invoke this option

in this way: -WWll,,-xx..

-SS Strip debugging symbols; only save local and global symbols.

-XX Strip local symbols whose names begin with `L'; save all other

symbols. (The compiler and assembler currently strip these

internally-generated labels by default, so they generally do not

appear in object files seen by the link editor.)

-SSpp Strip, edit and add debugging symbols so the debugger can used

most of the debugging symbols from the object files.

-SSii Strip duplicate debugging symbols from include files. This is

the default.

-bb Strip the base file's symbols from the output file. (The base

file is given as the argument to the -AA option.)

This option overlaps with a compiler option. If you use the compiler driver cc(1) to invoke ldclassic, invoke this option

in this way: -WWll,,-bb..

-SSnn Don't strip any symbols.

-eexxppoorrtteeddssyymmbboollsslliisstt 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 privateextern and will not be global in the output file.

The symbol names listed in filename must be one per line. Lead-

ing and trailing white space are not part of the symbol name.

Lines starting with # are ignored, as are lines with only white

space.

-uunneexxppoorrtteeddssyymmbboollsslliisstt 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 pri-

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

-nnoouuuuiidd

Do not emit an LCUUID load command in the linked output file.

-ddeeaaddssttrriipp

Remove blocks of code and data that are unreachable by the entry point or exported symbols.

-nnooddeeaaddssttrriippiinniittssaannddtteerrmmss

When specified along with -ddeeaaddssttrriipp cause all constructors and

destructors to never be dead stripped. The remaining options are infrequently used:

-vv Print the version of the linker.

-ww Suppresses all warning messages.

-nnooaarrcchhwwaarrnniinnggss

Suppresses warning messages about files that have the wrong

architecture for the -aarrcchh flag.

-aarrcchheerrrroorrssffaattaall

Cause the errors having to do with files that have the wrong architecture to be fatal and stop the link editor.

-MM 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 ldclassic, invoke this option

in this way: -WWll,,-MM..

-wwhhaattssllooaaddeedd

Display a single line listing each object file that is loaded. Names of objects in archives have the form libfoo.a(bar.o).

-ffiilleelliisstt listfile[,dirname]

Specifies that the linker should link the files listed in list-

file . This is an alternative to listing the files on the com-

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

-hheeaaddeerrppaadd value

Specifies the minimum amount of space ("padding") following the headers for the MHEXECUTE format and all output file types with

the dynamic linker. value is a hexadecimal number. When a seg-

ment'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 hheeaadd-

eerrppaadd option specifies the minimum size of this padding, which can be useful if the headers will be altered later. The default value is the larger of 2 * sizeof(struct section) so the program /usr/bin/objcunique can always add two section headers, or if

the output is an MHEXECUTE filetype and -pprreebbiinndd is specified 3

times the size of the LCPREBOUNDDYLIB load commands. 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.)

-hheeaaddeerrppaaddmmaaxxiinnssttaallllnnaammeess

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.

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

-AA 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. basefile 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 aa..oouutt 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 MHOBJECT. Note: It is strongly recommended that this option NOT be used, because the dyld package described in dyld(3) is a much easier alternative.

-ddyylliibbiinnssttaallllnnaammee 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 specified, the name specified in the -oo name option

will be used. This option is used as the libtool(1)

-iinnssttaallllnnaammee name option when its -ddyynnaammiicc option is specified.

-uummbbrreellllaa frameworkname

Specifies this is a subframework where frameworkname is the name of the umbrella framework this subframework is a part of.

Where frameworkname is the same as the argument to the -ffrraammee-

wwoorrkk frameworkname option. This subframework can then only be linked into the umbrella framework with the same frameworkname or another subframework with the same umbrella framework name. Any other attempt to statically link this subframework directly

will result in an error stating to link with the umbrella frame-

work instead. When building the umbrella framework that uses this subframework no additional options are required. However

the install name of the umbrella framework, required to be spec-

ified with -ddyylliibbiinnssttaallllnnaammee, must have the proper format for

an install name of a framework for the frameworkname of the umbrella framework to be determined.

-aalllloowwaabblleecclliieenntt clientname

Specifies that for this subframework the clientname can link with this subframework without error even though it is not part of the umbrella framework that this subframework is part of. The clientname can be another framework name or a name used by

bundles (see the -cclliieennttnnaammee clientname option below).

-cclliieennttnnaammee clientname

Specifies the clientname of a bundle for checking of allowable

clients of subframeworks (see the -aalllloowwaabblleecclliieenntt clientname

option above).

-ssuubbuummbbrreellllaa frameworkname

Specifies that the frameworkname being linked by a dynamic library is to be treated as one of the subframeworks with respect to twolevel namespace.

-ssuubblliibbrraarryy libraryname

Specifies that the libraryname being linked by a dynamic library is to be treated as one of the sublibraries with respect to twolevel namespace. For example the libraryname for /usr/lib/libobjcprofile.A.dylib would be libobjc.

-iinniitt 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 CALLONLOAD routines).

-rruunniinniittllaazziillyy

This option is obsolete.

-ddyylliibbccoommppaattiibbiilliittyyvveerrssiioonn number

For dynamic shared library files, this specifies the compatibil-

ity version number of the library. When a library is used by a

program, the compatibility version is checked and if the pro-

gram's version is greater that the library's version, it is an

error. The format of number is X[.Y[.Z]] where X must be a pos-

itive 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 checking is done when the library is used. This option is used as the libtool(1)

-ccoommppaattiibbiilliittyyvveerrssiioonn number option when its -ddyynnaammiicc option is

set.

-ddyylliibbccuurrrreennttvveerrssiioonn number

For dynamic shared library files, specifies the current version number of the library. The current version of the library can be obtained programmatically by the user of the library so it can determine 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 specified, it has

a value of 0. This option is used as the libtool(1) -ccuurr-

rreennttvveerrssiioonn number option when its -ddyynnaammiicc option is set.

-ssiinngglleemmoodduullee

When building a dynamic library build the library so that it contains only one module.

-mmuullttiimmoodduullee

When building a dynamic library build the library so that it contains one module for each object file linked in. This is the default.

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

-mmaaccoossxxvveerrssiioonnmmiinn version

This overrides the MMAACCOOSSXXDDEEPPLLOOYYMMEENNTTTTAARRGGEETT environment variable

(see below). Unlike other linker options, this one may be spec-

ified multiple times; only the last occurrence is effective.

The following environment variable is used to control the use of incom-

patible features in the output with respect to Mac OS X releases. MMAACCOOSSXXDDEEPPLLOOYYMMEENNTTTTAARRGGEETT 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 than 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 1100..11,, 1100..22

1100..33,, and 1100..44 with the default being 1100..44 for the i386 archi-

tecture and 1100..11 for all other architectures.

The following environment variables are used by Apple's Build and Inte-

gration team: LLDDTTRRAACCEEAARRCCHHIIVVEESS When this is set it causes a message of the form ``[Logging for XBS] Used static archive: filename'' for each static archive that has members linked into the output. LLDDTTRRAACCEEDDYYLLIIBBSS When this is set it causes a message of the form ``[Logging for XBS] Used dynamic library: filename'' for each dynamic library linked into the output. RRCCTTRRAACCEEPPRREEBBIINNDDIINNGGDDIISSAABBLLEEDD When this is set it causes a message of the form ``[Logging for XBS prebinding disabled for filename because reason''. Where

filename is the value of the -ffiinnaalloouuttppuutt argument if specified

or the value of the -oo argument.

-ffiinnaalloouuttppuutt filename

The argument filename is used in the above message when RCTRACEPREBINDINGDISABLED is set. LLDDTTRRAACCEEFFIILLEE

When this is set, messages displayed due to the LLDDTTRRAACCEEAARR-

CCHHIIVVEESS , LLDDTTRRAACCEEDDYYLLIIBBSS , and LLDDTTRRAACCEEPPRREEBBIINNDDIINNGGDDIISSAABBLLEEDD environment variables are printed to the file whose path is specified by this variable instead of stdout. LLDDSSPPLLIITTSSEEGGSSNNEEWWLLIIBBRRAARRIIEESS When set and MMAACCOOSSXXDDEEPPLLOOYYMMEENNTTTTAARRGGEETT is set to 10.4 or greater and the output is a dynamic library, and if the install name of the library is not listed the segment address table, and if the environment variable LLDDUUNNPPRREEBBOOUUNNDDLLIIBBRRAARRIIEESS is set with a file name with a list of library install names and the install name is not listed, then this is built as a split shared library.

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