[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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.
13.1 Porting libtool to new systems How to port libtool to new systems. 13.2 Tested platforms When libtool was last tested. 13.3 Platform quirks Information about different library systems. 13.4 libtool
script contentsConfiguration information that libtool uses. 13.5 Cheap tricks Making libtool maintainership easier.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Before you embark on porting libtool to an unsupported system, it is worthwhile to send e-mail to the libtool mailing list libtool@gnu.org, to make sure that you are not duplicating existing work.
If you find that any porting documentation is missing, please complain! Complaints with patches and improvements to the documentation, or to libtool itself, are more than welcome.
13.1.1 Information sources Where to find relevant documentation 13.1.2 Porting inter-library dependencies support Implementation details explained
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Once it is clear that a new port is necessary, you'll generally need the following information:
config.guess
for this system, so that you
can make changes to the libtool configuration process without affecting
other systems.
ld
and cc
ld.so
, rtld
, or equivalent
ldconfig
, or equivalent
If you know how to program the Bourne shell, then you can complete the port yourself; otherwise, you'll have to find somebody with the relevant skills who will do the work. People on the libtool mailing list are usually willing to volunteer to help you with new ports, so you can send the information to them.
To do the port yourself, you'll definitely need to modify the
libtool.m4
macros in order to make platform-specific changes to
the configuration process. You should search that file for the
PORTME
keyword, which will give you some hints on what you'll
need to change. In general, all that is involved is modifying the
appropriate configuration variables (see section 13.4 libtool
script contents).
Your best bet is to find an already-supported system that is similar to
yours, and make your changes based on that. In some cases, however,
your system will differ significantly from every other supported system,
and it may be necessary to add new configuration variables, and modify
the ltmain.in
script accordingly. Be sure to write to the
mailing list before you make changes to ltmain.in
, since they may
have advice on the most effective way of accomplishing what you want.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Since version 1.2c, libtool has re-introduced the ability to do inter-library dependency on some platforms, thanks to a patch by Toshio Kuratomi badger@prtr-13.ucsc.edu. Here's a shortened version of the message that contained his patch:
The basic architecture is this: in `libtool.m4', the person who writes libtool makes sure `$deplibs' is included in `$archive_cmds' somewhere and also sets the variable `$deplibs_check_method', and maybe `$file_magic_cmd' when `deplibs_check_method' is file_magic.
`deplibs_check_method' can be one of five things:
egrep
. When
file_magic_test_file is set by `libtool.m4', it is used as an
argument to `$file_magic_cmd' in order to verify whether the
regular expression matches its output, and warn the user otherwise.
ldd
. It is currently unused, and will probably be dropped in the
future.
Then in `ltmain.in' we have the real workhorse: a little initialization and postprocessing (to setup/release variables for use with eval echo libname_spec etc.) and a case statement that decides which method is being used. This is the real code... I wish I could condense it a little more, but I don't think I can without function calls. I've mostly optimized it (moved things out of loops, etc) but there is probably some fat left. I thought I should stop while I was ahead, work on whatever bugs you discover, etc before thinking about more than obvious optimizations.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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 (tools versions) release ------------------------------------------------------- alpha-dec-osf5.1 cc 1.3e ok (1.910) alpha-dec-osf4.0f gcc 1.3e ok (1.910) alpha-dec-osf4.0f cc 1.3e ok (1.910) alpha-dec-osf3.2 gcc 0.8 ok alpha-dec-osf3.2 cc 0.8 ok alpha-dec-osf2.1 gcc 1.2f NS alpha*-unknown-linux-gnu gcc 1.3b ok (egcs-1.1.2, GNU ld 2.9.1.0.23) hppa2.0w-hp-hpux11.00 cc 1.2f ok hppa2.0-hp-hpux10.20 cc 1.3.2 ok hppa1.1-hp-hpux10.20 gcc 1.2f ok hppa1.1-hp-hpux10.20 cc 1.3c ok (1.821) hppa1.1-hp-hpux10.10 gcc 1.2f ok hppa1.1-hp-hpux10.10 cc 1.2f ok hppa1.1-hp-hpux9.07 gcc 1.2f ok hppa1.1-hp-hpux9.07 cc 1.2f ok hppa1.1-hp-hpux9.05 gcc 1.2f ok hppa1.1-hp-hpux9.05 cc 1.2f ok hppa1.1-hp-hpux9.01 gcc 1.2f ok hppa1.1-hp-hpux9.01 cc 1.2f ok i*86-*-beos gcc 1.2f ok i*86-*-bsdi4.0.1 gcc 1.3c ok (gcc-2.7.2.1) i*86-*-bsdi4.0 gcc 1.2f ok i*86-*-bsdi3.1 gcc 1.2e NS i*86-*-bsdi3.0 gcc 1.2e NS i*86-*-bsdi2.1 gcc 1.2e NS i*86-pc-cygwin gcc 1.3b NS (egcs-1.1 stock b20.1 compiler) i*86-*-dguxR4.20MU01 gcc 1.2 ok i*86-*-freebsd4.3 gcc 1.3e ok (1.912) i*86-*-freebsdelf4.0 gcc 1.3c ok (egcs-1.1.2) i*86-*-freebsdelf3.2 gcc 1.3c ok (gcc-2.7.2.1) i*86-*-freebsdelf3.1 gcc 1.3c ok (gcc-2.7.2.1) i*86-*-freebsdelf3.0 gcc 1.3c ok i*86-*-freebsd3.0 gcc 1.2e ok i*86-*-freebsd2.2.8 gcc 1.3c ok (gcc-2.7.2.1) i*86-*-freebsd2.2.6 gcc 1.3b ok (egcs-1.1 & gcc-2.7.2.1, native ld) i*86-*-freebsd2.1.5 gcc 0.5 ok i*86-*-netbsd1.5 gcc 1.3e ok (1.901) (egcs-1.1.2) i*86-*-netbsd1.4 gcc 1.3c ok (egcs-1.1.1) i*86-*-netbsd1.4.3A gcc 1.3e ok (1.901) i*86-*-netbsd1.3.3 gcc 1.3c ok (gcc-2.7.2.2+myc2) i*86-*-netbsd1.3.2 gcc 1.2e ok i*86-*-netbsd1.3I gcc 1.2e ok (egcs 1.1?) i*86-*-netbsd1.2 gcc 0.9g ok i*86-*-linux-gnu gcc 1.3e ok (1.901) (Red Hat 7.0, gcc "2.96") i*86-*-linux-gnu gcc 1.4.2 ok (SuSE 7.0, gcc 2.95.2) i*86-*-linux-gnulibc1 gcc 1.2f ok i*86-*-openbsd2.5 gcc 1.3c ok (gcc-2.8.1) i*86-*-openbsd2.4 gcc 1.3c ok (gcc-2.8.1) i*86-*-solaris2.7 gcc 1.3b ok (egcs-1.1.2, native ld) i*86-*-solaris2.6 gcc 1.2f ok i*86-*-solaris2.5.1 gcc 1.2f ok i*86-ncr-sysv4.3.03 gcc 1.2f ok i*86-ncr-sysv4.3.03 cc 1.2e ok (cc -Hnocopyr) i*86-pc-sco3.2v5.0.5 cc 1.3c ok i*86-pc-sco3.2v5.0.5 gcc 1.3c ok (gcc 95q4c) i*86-pc-sco3.2v5.0.5 gcc 1.3c ok (egcs-1.1.2) i*86-sco-sysv5uw7.1.1 gcc 1.3e ok (1.901) (gcc-2.95.2, SCO linker) i*86-UnixWare7.1.0-sysv5 cc 1.3c ok i*86-UnixWare7.1.0-sysv5 gcc 1.3c ok (egcs-1.1.1) m68k-next-nextstep3 gcc 1.2f NS m68k-sun-sunos4.1.1 gcc 1.2f NS (gcc-2.5.7) m88k-dg-dguxR4.12TMU01 gcc 1.2 ok m88k-motorola-sysv4 gcc 1.3 ok (egcs-1.1.2) mips-sgi-irix6.5 gcc 1.2f ok (gcc-2.8.1) mips-sgi-irix6.4 gcc 1.2f ok mips-sgi-irix6.3 gcc 1.3b ok (egcs-1.1.2, native ld) mips-sgi-irix6.3 cc 1.3b ok (cc 7.0) mips-sgi-irix6.2 gcc 1.2f ok mips-sgi-irix6.2 cc 0.9 ok mips-sgi-irix5.3 gcc 1.2f ok (egcs-1.1.1) mips-sgi-irix5.3 gcc 1.2f NS (gcc-2.6.3) mips-sgi-irix5.3 cc 0.8 ok mips-sgi-irix5.2 gcc 1.3b ok (egcs-1.1.2, native ld) mips-sgi-irix5.2 cc 1.3b ok (cc 3.18) mips-sni-sysv4 cc 1.3.5 ok (Siemens C-compiler) mips-sni-sysv4 gcc 1.3.5 ok (gcc-2.7.2.3, GNU assembler 2.8.1, native ld) mipsel-unknown-openbsd2.1 gcc 1.0 ok powerpc-ibm-aix4.3.1.0 gcc 1.2f ok (egcs-1.1.1) powerpc-ibm-aix4.2.1.0 gcc 1.2f ok (egcs-1.1.1) powerpc-ibm-aix4.1.5.0 gcc 1.2f ok (egcs-1.1.1) powerpc-ibm-aix4.1.5.0 gcc 1.2f NS (gcc-2.8.1) powerpc-ibm-aix4.1.4.0 gcc 1.0 ok powerpc-ibm-aix4.1.4.0 xlc 1.0i ok rs6000-ibm-aix4.1.5.0 gcc 1.2f ok (gcc-2.7.2) rs6000-ibm-aix4.1.4.0 gcc 1.2f ok (gcc-2.7.2) rs6000-ibm-aix3.2.5 gcc 1.0i ok rs6000-ibm-aix3.2.5 xlc 1.0i ok sparc-sun-solaris2.8 gcc 1.4.2 ok (gcc-2.95.2 & native ld) sparc-sun-solaris2.8 gcc 1.4.2 ok (gcc-3.0.1 & GNU ld 2.11.2) sparc-sun-solaris2.7 gcc 1.3e ok (1.913) (gcc-2.95.3 & native ld) sparc-sun-solaris2.6 gcc 1.3e ok (1.913) (gcc-2.95.3 & native ld) sparc-sun-solaris2.5.1 gcc 1.4.2 ok (gcc-2.95.1 & GNU ld 2.9.1) sparc-sun-solaris2.5 gcc 1.3b ok (egcs-1.1.2, GNU ld 2.9.1 & native ld) sparc-sun-solaris2.5 cc 1.3b ok (SC 3.0.1) sparc-sun-solaris2.4 gcc 1.0a ok sparc-sun-solaris2.4 cc 1.0a ok sparc-sun-solaris2.3 gcc 1.2f ok sparc-sun-sunos4.1.4 gcc 1.2f ok sparc-sun-sunos4.1.4 cc 1.0f ok sparc-sun-sunos4.1.3_U1 gcc 1.2f ok sparc-sun-sunos4.1.3C gcc 1.2f ok sparc-sun-sunos4.1.3 gcc 1.3b ok (egcs-1.1.2, GNU ld 2.9.1 & native ld) sparc-sun-sunos4.1.3 cc 1.3b ok sparc-unknown-bsdi4.0 gcc 1.2c ok sparc-unknown-linux-gnulibc1 gcc 1.2f ok sparc-unknown-linux-gnu gcc 1.3b ok (egcs-1.1.2, GNU ld 2.9.1.0.23) sparc64-unknown-linux-gnu gcc 1.2f ok Notes: - "ok" means "all tests passed". - "NS" means "Not Shared", but OK for static libraries |
Note: The vendor-distributed HP-UX sed
(1) programs are horribly
broken, and cannot handle libtool's requirements, so users may report
unusual problems. There is no workaround except to install a working
sed
(such as GNU sed
) on these systems.
Note: The vendor-distributed NCR MP-RAS cc
programs emits
copyright on standard error that confuse tests on size of
`conftest.err'. The workaround is to specify CC
when run configure
with CC='cc -Hnocopyr'.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
This section is dedicated to the sanity of the libtool maintainers. 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 can be difficult to understand just by reading it from top to bottom. This section helps show why libtool does things a certain way. Combined with the scripts themselves, you should have a better sense of how to improve libtool, or write your own.
13.3.1 References Finding more information. 13.3.2 Compilers Creating object files from source files. 13.3.3 Reloadable objects Binding object files together. 13.3.4 Multiple dependencies Removing duplicate dependant libraries. 13.3.5 Archivers Programs that create static archives.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The following is a list of valuable documentation references:
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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
This is the GNU C compiler, which is also the system compiler for many free operating systems (FreeBSD, GNU/Hurd, GNU/Linux, Lites, NetBSD, and OpenBSD, to name a few).
The `-fpic' or `-fPIC' flags can be used to generate position-independent code. `-fPIC' is guaranteed to generate working code, but the code is slower on m68k, m88k, and Sparc chips. However, using `-fpic' on those chips imposes arbitrary size limits on the shared libraries.
The rest of this subsection lists compilers by the operating system that they are bundled with:
aix3*
aix4*
hpux10*
osf3*
solaris2*
sunos4*
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
On most modern platforms the order that dependent libraries are listed has no effect on object generation. In theory, there are platforms which require libraries which provide missing symbols to other libraries to listed after those libraries whose symbols they provide.
Particularly, if a pair of static archives each resolve some of the other's symbols, it might be necessary to list one of those archives both before and after the other one. Libtool does not currently cope with this situation well, since dupicate libraries are removed from thr link line.
If you find yourself developing on a host that requires you to list libraries multiple times in order for it to generate correctly linked objects, you can defeat libtool's removal algorithm like this:
$ libtool ... -lfoo -lbar -Wl,-lfoo |
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
libtool
script contents
Since version 1.4, the libtool
script is generated by
configure
(see section 5.3 Configuring libtool). In earlier versions,
configure
achieved this by calling a helper script called
`ltconfig'. 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 through 1.3
inlined the contents of ltmain.sh
into the generated
libtool
, which improved performance on many systems. The tests
that `ltconfig' used to perform are now kept in `libtool.m4'
where thay can be written using Autoconf. This has the runtime
performance benefits of inlined ltmain.sh
, and improves
the build time a little while considerably easing the amount of raw
shell code that used to need maintaining.
The convention used for naming variables which hold shell commands for
delayed evaluation, is to use the suffix _cmd
where a single
line of valid shell script is needed, and the suffix _cmds
where
multiple lines of shell script may be delayed for later
evaluation. By convention, _cmds
variables delimit the
evaluation units with the ~
character where necessary.
Here is a listing of each of the configuration variables, and how they
are used within ltmain.sh
(see section 5.3 Configuring libtool):
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 |
-c
and -o
options
simultaneously. Set to `yes' or `no'.
dlopen
is supported on the platform.
Set to `yes' or `no'.
dlopen
the executable itself.
Set to `yes' or `no'.
dlopen
the executable itself, when it
is linked statically (`-all-static'). Set to `yes' or
`no'.
echo
program which does not interpret backslashes as an
escape character.
$ eval "$NM progname | $global_symbol_pipe" D symbol1 C-symbol1 T symbol2 C-symbol2 C symbol3 C-symbol3 ... $ |
The first column contains the symbol type (used to tell data from code on some platforms), but its meaning is system dependent.
dlopen
and to
link against a library without 'lib' prefix,
i.e. it requires hardcode_direct to be `yes'.
char
.
fast_install
. The default value is `unknown', which is
equivalent to `no'.
striplib
) or static (old_striplib
)
library, respectively. If these variables are empty, the strip flag
in the install mode will be ignored for libraries (see section 4.4 Install mode).
-L
also augment the search path.
${wl}some-flag
.
Variables ending in `_cmds' or `_eval' contain a
`~'-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.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Here are a few tricks that you can use in order to make maintainership easier:
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, /home/src/libtool/libtool
is a libtool script that has been
configured for your platform, and ~/bin
is a directory in your
PATH:
trick$ cd ~/bin trick$ sed '/^# ltmain\.sh/q' /home/src/libtool/libtool > libtool trick$ echo '. /home/src/libtool/ltmain.in' >> libtool trick$ chmod +x libtool trick$ libtool --version ltmain.sh (GNU @PACKAGE@) @VERSION@@TIMESTAMP@ trick$ |
The output of the final `libtool --version' command shows that the
ltmain.in
script is being used directly. Now, modify
~/bin/libtool
or /home/src/libtool/ltmain.in
directly in
order to test new changes without having to rerun configure
.
[ << ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |