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:
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-aix126.96.36.199 xlc 1.0i ok powerpc-ibm-aix188.8.131.52 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:
The rest of this subsection lists compilers by the operating system that they are bundled with:
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,
ar ts command, instead.
libtool script is generated by
(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,
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
ltconfigscript, to prevent mismatches between the configuration information in
libtool, and how that information is used in
nmprogram, 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 ... $
Variables ending in `_cmds' or `_eval' contain a
semicolon-separated list of commands that are
evaled 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
evaled before being used by
Here are a few tricks that you can use in order to make maintainership easier:
ltmain.in, I keep a permanent
libtoolscript in my PATH, which sources
ltmain.indirectly. The following steps describe how to create such a script, where
/home/src/libtoolis the directory containing the libtool source tree, and
/home/src/libtool/libtoolis 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.