LIBTOOL(1)LIBTOOL(1)NAME
libtool - create libraries
ranlib - add or update the table of contents of archive libraries
SYNOPSIS
libtool -static-o output [ -sac ] [ - ] [ -arch_only arch_type ]
file... [-filelist listfile[,dirname]]
libtool -dynamic-o output [ -install_name name ] [
-compatiblity_version number ] [ -current_version number ] [ link
editor flags ] [ -v ] [ - ] [ -arch_only arch_type ] file...
[-filelist listfile[,dirname]]
ranlib [ -sact ] [ - ] archive...
DESCRIPTION
The libtool command takes the specified input object files and creates
a library for use with the link editor, ld(1). The library's name is
specified by output (the argument to the -o flag). The input object
files may be in any correct format that contains object files (``fat''
files, archives, object files). Libtool will not put any non-object
input file into the output library (unlike ranlib, which allows this in
the archives it operates on).
When producing a ``fat'' file from objects of the same CPU type and
differing CPU subtypes, libtool and ranlib create at most one library
for each CPU type, rather than a separate library in a fat file for
each of the unique pairings of CPU type and CPU subtype. Thus, the
resulting CPU subtype for each library is the _ALL CPU subtype for that
CPU type. This strategy strongly encourages the implementor of a
library to create one library that chooses optimum code to run at run
time, rather than at link time.
Libtool can create either dynamically linked shared libraries, with
-dynamic, or statically linked (archive) libraries, with -static.
DYNAMICALLY LINKED SHARED LIBRARIES
Dynamically linked libraries, unlike statically linked libraries, are
Mach-O format files and not ar(5) format files. Dynamically linked
libraries have two restrictions: No symbol may be defined in more than
one object file and no common symbol can be used. To maximize sharing
of a dynamically linked shared library the objects should be compiled
with the -dynamic flag of cc(1) to produce indirect undefined
references and possition-independent code. To build a dynamically
linked library, libtool, runs the link editor, ld(1), with -dylib once
for each architecutre present in the input objects and then lipo(1) to
create a fat file if needed.
ARCHIVE (or statically linked) LIBRARIES
Libtool with -static is intended to replace ar(5) and ranlib. For
backward compatibility, ranlib is still available, and it supports fat
files. Ranlib adds or updates the table of contents to each archive so
it can be linked by the link editor, ld(1). The table of contents is
an archive member at the beginning of the archive that indicates which
symbols are defined in which library members. Because ranlib rewrites
the archive, sufficient temporary file space must be available in the
file system that contains the current directory. Ranlib takes all
correct forms of libraries (fat files containing archives, and simple
archives) and updates the table of contents for all archives in the
file. Ranlib also takes one common incorrect form of archive, an
archive whose members are fat object files, adding or updating the
table of contents and producing the library in correct form (a fat file
containing multiple archives).
The archive member name for a table of contents begins with
``__.SYMDEF''. Currently, there are two types of table of contents
produced by libtool -static and ranlib and understood by the link
editor, ld(1). These are explained below, under the -s and -a options.
OPTIONS
The following options pertain to libtool only.
-static
Produce a statically linked (archive) library from the input
files. This is the default.
-dynamic
Produce a dynamically linked shared library from the input
files.
-install_name name
For a dynamic shared library this specifies the file name the
library will be installed in for programs that use it. If this
is not specified the name specified by the -o output option will
be used.
-compatibility_version number
For a dynamic shared library this specifies the compatibility
version number of the library. When a library is used the
compatibility version is checked and if the user's version is
greater that the library's version, an error message is printed
and the using program exits. 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 a
positive non-zero numbers less than or equal to 255. If this is
not specified then it has a value of 0 and no checking is done
when the library is used.
-current_version number
For dynamic shared library files this specifies the current
version number of the library. The program using the library
can obtain the current version of the library programmatically
to 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 a positive non-zero numbers less
than or equal to 255. If this is not specified then it has a
value of 0.
link editor flags
For a dynamic shared library the following ld(1) flags are
accepted and passed through: -lx, -Ldir, -ysym, -seg1addr,
-segprot, -segalign, -sectcreate, -sectorder, -sectorder_detail,
-sectalign, -undefined, -read_only_relocs, -prebind, -framework,
-F. See the ld(1) man page for details on these flags. The
flag -image_base is a synonym for -seg1addr.
-v Verbose mode, which prints the ld(1) commands and lipo(1)
commands executed.
-filelist listfile[,dirname]
The listfile contains a list of file names and is an alternative
way of specifiying file names 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 then it is
prepended to each name in the list file.
-arch_only arch_type
This option causes libtool to build a library only for the
specified arch_type and ignores all other architectures in the
input files.
The following options pertain to the table of contents for an archive
library, and apply to both libtool -static and ranlib:
-s Produce the preferred type of table of contents, which results
in faster link editing when linking with the archive. The order
of the table of contents is sorted by symbol name. The library
member name of this type of table of contents is ``__.SYMDEF
SORTED''. This type of table of contents can only be produced
when the library does not have multiple members that define the
same symbol. This is the default.
-a Produce the original type of table of contents, whose order is
based on the order of the members in the archive. The library
member name of this type of table of contents is ``__.SYMDEF''.
This type of table of contents must be used when the library has
multiple members that define the same symbol.
-c Include common symbols as definitions with respect to the table
of contents. This is seldom the intended behavior for linking
from a library, as it forces the linking of a library member
just because it uses an uninitialized global that is undefined
at that point in the linking. This option is included only
because this was the original behavior of ranlib. This option
is not the default.
For compatibility, the following ranlib option is accepted (but
ignored):
-t This option used to request that ranlib only ``touch'' the
archives instead of modifying them. The option is now ignored,
and the table of contents is rebuilt.
One other option applies to both libtool and ranlib:
- Treat all remaining arguments as names of files (or archives)
and not as options.
SEE ALSOld(1), ar(1), otool(1), make(1), redo_prebinding(1), ar(5)BUGS
The way libraries used to be created, errors were possible if the
library was modified with ar(1) and the table of contents was not
updated by rerunning ranlib(1). Thus the link editor, ld, warns when
the modification date of a library is more recent than the creation
date of its table of contents. Unfortunately, this means that you get
the warning even if you only copy the library.
NeXT Software, Inc. March 28, 1996 LIBTOOL(1)
