This chapter contains information that the libtool maintainer finds important. It will be of no use to you unless you are considering porting libtool to new systems, or writing your own libtool.
To port libtool to a new system, you'll generally need the following information:
ld(1)
and cc(1)
ld.so(8)
, rtld(8)
, or equivalent
ldconfig(8)
, or equivalent
This table describes when libtool was last known to be tested on platforms where it claims to support shared libraries:
-------------------------------------------------------- canonical host name compiler libtool results release -------------------------------------------------------- alpha-dec-osf3.2 cc 0.8 ok alpha-dec-osf3.2 gcc 0.8 ok alpha-dec-osf4.0 cc 1.0f ok alpha-dec-osf4.0 gcc 1.0f ok alpha-unknown-linux-gnu gcc 0.9h ok hppa1.1-hp-hpux9.07 cc 1.0f ok hppa1.1-hp-hpux9.07 gcc 1.0f ok hppa1.1-hp-hpux10.10 cc 0.9h ok hppa1.1-hp-hpux10.10 gcc 0.9h ok i386-unknown-freebsd2.1.5 gcc 0.5 ok i386-unknown-gnu0.0 gcc 0.5 ok i386-unknown-netbsd1.2 gcc 0.9g ok i586-pc-linux-gnulibc1 gcc 1.0i ok i586-pc-linux-gnu gcc 1.0i ok mips-sgi-irix5.2 gcc 1.0i ok mips-sgi-irix5.3 cc 0.8 ok mips-sgi-irix5.3 gcc 0.8 ok mips-sgi-irix6.2 cc 0.9 ok mips-sgi-irix6.3 cc 1.0f ok mips-sgi-irix6.3 gcc 1.0i ok mips-sgi-irix6.3 irix5-gcc 1.0f ok mipsel-unknown-openbsd2.1 gcc 1.0 ok powerpc-ibm-aix4.1.4.0 xlc 1.0i ok powerpc-ibm-aix4.1.4.0 gcc 1.0 ok rs6000-ibm-aix3.2.5 xlc 1.0i ok rs6000-ibm-aix3.2.5 gcc 1.0i ok* sparc-sun-linux-gnu2.1.23 gcc 0.9h ok sparc-sun-sunos4.1.3 gcc 1.0i ok sparc-sun-sunos4.1.4 cc 1.0f ok sparc-sun-sunos4.1.4 gcc 1.0f ok sparc-sun-solaris2.4 cc 1.0a ok sparc-sun-solaris2.4 gcc 1.0a ok sparc-sun-solaris2.5 cc 1.0f ok sparc-sun-solaris2.5 gcc 1.0i ok sparc-sun-solaris2.6 gcc 1.0i ok -------------------------------------------------------- * Some versions of GCC's collect2 linker program cannot link trivial static binaries on AIX 3. For these configurations, libtool's `-static' flag has no effect.
This section is dedicated to the sanity of the libtool maintainer. It describes the programs that libtool uses, how they vary from system to system, and how to test for them.
Because libtool is a shell script, it is difficult to understand just by reading it from top to bottom. This section helps show why libtool does things a certain way. After reading it, then reading the scripts themselves, you should have a better sense of how to improve libtool, or write your own.
The following is a list of valuable documentation references:
The only compiler characteristics that affect libtool are the flags needed (if any) to generate PIC objects. In general, if a C compiler supports certain PIC flags, then any derivative compilers support the same flags. Until there are some noteworthy exceptions to this rule, this section will document only C compilers.
The following C compilers have standard command line options, regardless of the platform:
gcc
The rest of this subsection lists compilers by the operating system that they are bundled with:
aix3*
aix4*
hpux10*
osf3*
solaris2*
sunos4*
On all known systems, a reloadable object can be created by running ld -r -o output.o input1.o input2.o. This reloadable object may be treated as exactly equivalent to other objects.
On all known systems, building a static library can be accomplished by running ar cru libname.a obj1.o obj2.o ..., where the `.a' file is the output library, and each `.o' file is an object file.
On all known systems, if there is a program named ranlib
, then it
must be used to "bless" the created library before linking against it,
with the ranlib libname.a command. Some systems, like Irix,
use the ar ts
command, instead.
libtool
script contents
The libtool
script is generated by ltconfig
(see section 5.3 Configuring libtool). From libtool version 0.7 to 1.0, this script
simply set shell variables, then sourced the libtool backend,
ltmain.sh
. ltconfig
from libtool version 1.1 and later
inlines the contents of ltmain.sh
into the generated
libtool
, which improves performance on many systems.
Here is a listing of each of the configuration variables, and how they
are used within ltmain.sh
:
ltconfig
script, to
prevent mismatches between the configuration information in
libtool
, and how that information is used in ltmain.sh
.
nm
program, which produces listings
of global symbols in one the following formats:
address C global-variable-name address D global-variable-name address T global-function-name
echo(1)
program which does not interpret backslashes as an
escape character.
$ $NM | $global_symbol_pipe symbol1 C-symbol1 symbol2 C-symbol2 symbol3 C-symbol3 ... $
char
.
Variables ending in `_cmds' or `_eval' contain a
semicolon-separated list of commands that are eval
ed one after
another. If any of the commands return a nonzero exit status, libtool
generally exits with an error message.
Variables ending in `_spec' are eval
ed before being used by
libtool.
Here are a few tricks that you can use in order to make maintainership easier:
ltconfig.in
or ltmain.in
, I keep a permanent
libtool
script in my PATH, which sources ltmain.in
directly.
The following steps describe how to create such a script, where
/home/src/libtool
is the directory containing the libtool source
tree, and /home/src/libtool/libtool
is a libtool script that has
been configured for your platform, and :
trick$ sed '/^# ltmain\.sh/q' /usr/local/bin/libtool > ~/bin/libtool trick$ cat >> ~/bin/libtool LTCONFIG_VERSION="@VERSION@" . /home/src/libtool/ltmain.in trick$ chmod +x ~/bin/libtool trick$
Go to the first, previous, next, last section, table of contents.