LIBTOOL(1) — UNIX Programmer’s Manual
NAME
libtool − create libraries
ranlib − add or update the table of contents of archive libraries
SYNOPSIS
libtool −o output [ −sac ] [ − ] files ...
ranlib [ −sact ] [ − ] archive ...
DESCRIPTION
Libtool creates a library for use with the link editor, ld(1), in the file specified in the −o output argument from the specified input object files. 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 file in the input files in the output library (unlike ranlib which allows this in the archives it operates on).
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 a file at the beginning of the archive that indicates which symbols are defined in which library members. Ranlib rewrites the archive, so that sufficient temporary file space must be available in the file system which 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 who’s members are fat object files, and adds or updates the table of contents and produces the library in correct form (a fat file containing multiple archives).
The name for a table of contents begins with “__.SYMDEF”. Currently there are two types of table of contents produced by libtool and ranlib and understood by the link editor, ld(1).
Libtool and ranlib when producing a fat file from objects of the same cputype and differing cpusubtypes these programs will create at most one library for each cputype and not a separate library in a fat file for each of the unique cputype and cpusubtype pairs. The resulting cpusubtype for each library will be the _ALL cpusubtype for that cputype. The goal is the library implementor should be strongly encouraged to create one library that chooses optimum code to run at run time rather than at link time.
The options for the format and contents of the table of contents are:
−s Produced 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 who’s 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 ever the behavior that is intended for linking from a library as it will force the linking of a library member just because it uses an uninitialized global that is undefined at that point in the linking. This is only included as an option because this was the original behavior of ranlib. This is not the default.
For ranlib the following option is recognized for compatibility:
−t This option was only “touch” the archives and do not modify them. It is currently ignored and the table of contents is rebuilt.
The one other option for both libtool and ranlib is:
− Treat all remaining arguments as names of files (or archives) and not as options.
SEE ALSO
ld(1), ar(1), otool(1), make(1), ar(5)
BUGS
Because of the original design of library creation using ar(1) and the table of contents of the library produced by ranlib(1) errors were possible (where the library could be 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; but this means that you get the warning even if you only copy the library.
NeXT Computer, Inc. — September 30, 1992 (Release 3.1)