[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

14. Maintenance notes for libtool

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.

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

14.1 Porting libtool to new systems

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.

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

14.1.1 Information sources

Once it is clear that a new port is necessary, you'll generally need the following information:

canonical system name

You need the output of config.guess for this system, so that you can make changes to the libtool configuration process without affecting other systems.

man pages for ld and cc

These generally describe what flags are used to generate PIC, to create shared libraries, and to link against only static libraries. You may need to follow some cross references to find the information that is required.

man pages for ld.so, rtld, or equivalent

These are a valuable resource for understanding how shared libraries are loaded on the system.

man page for ldconfig, or equivalent

This page usually describes how to install shared libraries.

output from ls -l /lib /usr/lib

This shows the naming convention for shared libraries on the system, including which names should be symbolic links.

any additional documentation

Some systems have special documentation on how to build and install shared libraries.

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 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] [ ? ]

14.1.2 Porting inter-library dependencies support

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:

`file_magic [regex]'

looks in the library link path for libraries that have the right libname. Then it runs `$file_magic_cmd' on the library and checks for a match against the extended regular expression regex. 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.


just checks whether it is possible to link a program out of a list of libraries, and checks which of those are listed in the output of ldd. It is currently unused, and will probably be dropped in the future.


will pass everything without any checking. This may work on platforms in which code is position-independent by default and inter-library dependencies are properly supported by the dynamic linker, for example, on DEC OSF/1 3 and 4.


It causes deplibs to be reassigned `deplibs=""'. That way `archive_cmds' can contain deplibs on all platforms, but not have deplibs used unless needed.


is the default for all systems unless overridden in `libtool.m4'. It is the same as `none', but it documents that we really don't know what the correct value should be, and we welcome patches that improve it.

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 the method that 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] [ ? ]

14.2 Tested platforms

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
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
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
i*86-*-freebsdelf3.2            gcc      1.3c     ok
i*86-*-freebsdelf3.1            gcc      1.3c     ok
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
i*86-*-freebsd2.2.6             gcc      1.3b     ok
  (egcs-1.1 & gcc-, native ld)
i*86-*-freebsd2.1.5             gcc      0.5      ok
i*86-*-netbsd1.5                gcc      1.3e     ok (1.901)
i*86-*-netbsd1.4                gcc      1.3c     ok
i*86-*-netbsd1.4.3A             gcc      1.3e     ok (1.901)
i*86-*-netbsd1.3.3              gcc      1.3c     ok
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.3e	  ok (1.911)
  (SuSE 7.0, gcc 2.95.2)
i*86-*-linux-gnulibc1           gcc      1.2f     ok
i*86-*-openbsd2.5               gcc      1.3c     ok
i*86-*-openbsd2.4               gcc      1.3c     ok
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
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
m68k-next-nextstep3             gcc      1.2f     NS
m68k-sun-sunos4.1.1             gcc      1.2f     NS
m88k-dg-dguxR4.12TMU01          gcc      1.2      ok
m88k-motorola-sysv4             gcc      1.3      ok
mips-sgi-irix6.5                gcc      1.2f     ok
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
mips-sgi-irix5.3                gcc      1.2f     NS
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-, GNU assembler 2.8.1, native ld) 
mipsel-unknown-openbsd2.1       gcc      1.0      ok
powerpc-apple-darwin6.4         gcc      1.5      ok
(apple dev tools released 12/2002)
powerpc-ibm-aix4.3.1.0          gcc      1.2f     ok
powerpc-ibm-aix4.2.1.0          gcc      1.2f     ok
powerpc-ibm-aix4.1.5.0          gcc      1.2f     ok
powerpc-ibm-aix4.1.5.0          gcc      1.2f     NS
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
rs6000-ibm-aix4.1.4.0           gcc      1.2f     ok
rs6000-ibm-aix3.2.5             gcc      1.0i     ok
rs6000-ibm-aix3.2.5             xlc      1.0i     ok
sparc-sun-solaris2.8		gcc	 1.3e	  ok (1.913)
  (gcc-2.95.3 & native ld)
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.3e     ok (1.911)
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
sparc64-unknown-linux-gnu       gcc      1.2f     ok

- "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] [ ? ]

14.3 Platform quirks

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.

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

14.3.1 References

The following is a list of valuable documentation references:

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

14.3.2 Compilers

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:


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:


Most AIX compilers have no PIC flags, since AIX (with the exception of AIX for IA-64) runs on PowerPC and RS/6000 chips. (14)


Use `+Z' to generate PIC.


Digital/UNIX 3.x does not have PIC flags, at least not on the PowerPC platform.


Use `-KPIC' to generate PIC.


Use `-PIC' to generate PIC.

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

14.3.3 Reloadable objects

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] [ ? ]

14.3.4 Multiple dependencies

On most modern platforms the order in which dependent libraries are listed has no effect on object generation. In theory, there are platforms that require libraries that provide missing symbols to other libraries to be 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 duplicate libraries are removed from the link line by default. Libtool provides the command line option `--preserve-dup-deps' to preserve all duplicate dependencies in cases where it is necessary.

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

14.3.5 Archivers

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] [ ? ]

14.4 libtool script contents

Since version 1.4, the libtool script is generated by configure (see section 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 they 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 that 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 Configuring libtool):

Variable: AR

The name of the system library archiver.

Variable: CC

The name of the compiler used to configure libtool. This will always contain the compiler for the current language (see section Tags).

Variable: ECHO

An echo program that does not interpret backslashes as an escape character. It may be given only one argument, so due quoting is necessary.

Variable: LD

The name of the linker that libtool should use internally for reloadable linking and possibly shared libraries.

Variable: LTCC
Variable: LTCFLAGS

The name of the C compiler and C compiler flags used to configure libtool.

Variable: NM

The name of a BSD- or MS-compatible program that produces listings of global symbols. For BSD nm, the symbols should be in one the following formats:

address C global-variable-name
address D global-variable-name
address T global-function-name

For MS dumpbin, the symbols should be in one of the following formats:

counter size    UNDEF    notype       External     | global-var
counter address section  notype       External     | global-var
counter address section  notype ()    External     | global-func

The size of the global variables are not zero and the section of the global functions are not "UNDEF". Symbols in "pick any" sections ("pick any" appears in the section header) are not global either.

Variable: RANLIB

Set to the name of the ranlib program, if any.

Variable: allow_undefined_flag

The flag that is used by `archive_cmds' in order to declare that there will be unresolved symbols in the resulting shared library. Empty, if no such flag is required. Set to `unsupported' if there is no way to generate a shared library with references to symbols that aren't defined in that library.

Variable: always_export_symbols

Whether libtool should automatically generate a list of exported symbols using export_symbols_cmds before linking an archive. Set to `yes' or `no'. Default is `no'.

Variable: archive_cmds
Variable: archive_expsym_cmds
Variable: old_archive_cmds

Commands used to create shared libraries, shared libraries with `-export-symbols' and static libraries, respectively.

Variable: old_archive_from_new_cmds

If the shared library depends on a static library, `old_archive_from_new_cmds' contains the commands used to create that static library. If this variable is not empty, `old_archive_cmds' is not used.

Variable: old_archive_from_expsyms_cmds

If a static library must be created from the export symbol list in order to correctly link with a shared library, `old_archive_from_expsyms_cmds' contains the commands needed to create that static library. When these commands are executed, the variable soname contains the name of the shared library in question, and the $objdir/$newlib contains the path of the static library these commands should build. After executing these commands, libtool will proceed to link against $objdir/$newlib instead of soname.

Variable: build
Variable: build_alias
Variable: build_os

Set to the specified and canonical names of the system that libtool was built on.

Variable: build_libtool_libs

Whether libtool should build shared libraries on this system. Set to `yes' or `no'.

Variable: build_old_libs

Whether libtool should build static libraries on this system. Set to `yes' or `no'.

Variable: compiler_c_o

Whether the compiler supports the `-c' and `-o' options simultaneously. Set to `yes' or `no'.

Variable: compiler_needs_object

Whether the compiler has to see an object listed on the command line in order to successfully invoke the linker. If `no', then a set of convenience archives or a set of object file names can be passed via linker-specific options or linker scripts.

Variable: dlopen_support

Whether dlopen is supported on the platform. Set to `yes' or `no'.

Variable: dlopen_self

Whether it is possible to dlopen the executable itself. Set to `yes' or `no'.

Variable: dlopen_self_static

Whether it is possible to dlopen the executable itself, when it is linked statically (`-all-static'). Set to `yes' or `no'.

Variable: exclude_expsyms

List of symbols that should not be listed in the preloaded symbols.

Variable: export_dynamic_flag_spec

Compiler link flag that allows a dlopened shared library to reference symbols that are defined in the program.

Variable: export_symbols_cmds

Commands to extract exported symbols from libobjs to the file export_symbols.

Variable: extract_expsyms_cmds

Commands to extract the exported symbols list from a shared library. These commands are executed if there is no file $objdir/$soname-def, and should write the names of the exported symbols to that file, for the use of `old_archive_from_expsyms_cmds'.

Variable: fast_install

Determines whether libtool will privilege the installer or the developer. The assumption is that installers will seldom run programs in the build tree, and the developer will seldom install. This is only meaningful on platforms where shlibpath_overrides_runpath is not `yes', so fast_install will be set to `needless' in this case. If fast_install set to `yes', libtool will create programs that search for installed libraries, and, if a program is run in the build tree, a new copy will be linked on-demand to use the yet-to-be-installed libraries. If set to `no', libtool will create programs that use the yet-to-be-installed libraries, and will link a new copy of the program at install time. The default value is `yes' or `needless', depending on platform and configuration flags, and it can be turned from `yes' to `no' with the configure flag `--disable-fast-install'.

On some systems, the linker always hardcodes paths to dependent libraries into the output. In this case, fast_install is never set to `yes', and relinking at install time is triggered. This also means that DESTDIR installation does not work as expected.

Variable: finish_cmds

Commands to tell the dynamic linker how to find shared libraries in a specific directory.

Variable: finish_eval

Same as finish_cmds, except the commands are not displayed.

Variable: fix_srcfile_path

Expression to fix the shell variable `$srcfile' for the compiler.

Variable: global_symbol_pipe

A pipeline that takes the output of NM, and produces a listing of raw symbols followed by their C names. For example:

$ 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) but its meaning is system dependent.

Variable: global_symbol_to_cdecl

A pipeline that translates the output of global_symbol_pipe into proper C declarations. Since some platforms, such as HP/UX, have linkers that differentiate code from data, data symbols are declared as data, and code symbols are declared as functions.

Variable: hardcode_action

Either `immediate' or `relink', depending on whether shared library paths can be hardcoded into executables before they are installed, or if they need to be relinked.

Variable: hardcode_direct

Set to `yes' or `no', depending on whether the linker hardcodes directories if a library is directly specified on the command line (such as `dir/libname.a') when hardcode_libdir_flag_spec is specified.

Variable: hardcode_direct_absolute

Some architectures hardcode "absolute" library directories that can not be overridden by shlibpath_var when hardcode_direct is `yes'. In that case set hardcode_direct_absolute to `yes', or otherwise `no'.

Variable: hardcode_into_libs

Whether the platform supports hardcoding of run-paths into libraries. If enabled, linking of programs will be much simpler but libraries will need to be relinked during installation. Set to `yes' or `no'.

Variable: hardcode_libdir_flag_spec

Flag to hardcode a libdir variable into a binary, so that the dynamic linker searches libdir for shared libraries at runtime. If it is empty, libtool will try to use some other hardcoding mechanism.

Variable: hardcode_libdir_separator

If the compiler only accepts a single hardcode_libdir_flag, then this variable contains the string that should separate multiple arguments to that flag.

Variable: hardcode_minus_L

Set to `yes' or `no', depending on whether the linker hardcodes directories specified by `-L' flags into the resulting executable when hardcode_libdir_flag_spec is specified.

Variable: hardcode_shlibpath_var

Set to `yes' or `no', depending on whether the linker hardcodes directories by writing the contents of `$shlibpath_var' into the resulting executable when hardcode_libdir_flag_spec is specified. Set to `unsupported' if directories specified by `$shlibpath_var' are searched at run time, but not at link time.

Variable: host
Variable: host_alias
Variable: host_os

Set to the specified and canonical names of the system that libtool was configured for.

Variable: include_expsyms

List of symbols that must always be exported when using export_symbols.

Variable: inherit_rpath

Whether the linker adds runtime paths of dependency libraries to the runtime path list, requiring libtool to relink the output when installing. Set to `yes' or `no'. Default is `no'.

Variable: libext

The standard old archive suffix (normally `a').

Variable: libname_spec

The format of a library name prefix. On all Unix systems, static libraries are called `libname.a', but on some systems (such as OS/2 or MS-DOS), the library is just called `name.a'.

Variable: library_names_spec

A list of shared library names. The first is the name of the file, the rest are symbolic links to the file. The name in the list is the file name that the linker finds when given `-lname'.

Variable: link_all_deplibs

Whether libtool must link a program against all its dependency libraries. Set to `yes' or `no'. Default is `unknown', which is a synonym for `yes'.

Variable: link_static_flag

Linker flag (passed through the C compiler) used to prevent dynamic linking.

Variable: macro_version
Variable: macro_revision

The release and CVS revision from which the libtool.m4 macros were taken. This is used to ensure that macros and ltmain.sh correspond to the same Libtool version.

Variable: max_cmd_len

The approximate longest command line that can be passed to `$SHELL' without being truncated, as computed by `LT_CMD_MAX_LEN'.

Variable: need_lib_prefix

Whether we can dlopen modules without a `lib' prefix. Set to `yes' or `no'. By default, it is `unknown', which means the same as `yes', but documents that we are not really sure about it. `no' means that it is possible to dlopen a module without the `lib' prefix.

Variable: need_version

Whether versioning is required for libraries, i.e. whether the dynamic linker requires a version suffix for all libraries. Set to `yes' or `no'. By default, it is `unknown', which means the same as `yes', but documents that we are not really sure about it.

Variable: need_locks

Whether files must be locked to prevent conflicts when compiling simultaneously. Set to `yes' or `no'.

Variable: no_builtin_flag

Compiler flag to disable builtin functions that conflict with declaring external global symbols as char.

Variable: no_undefined_flag

The flag that is used by `archive_cmds' in order to declare that there will be no unresolved symbols in the resulting shared library. Empty, if no such flag is required.

Variable: objdir

The name of the directory that contains temporary libtool files.

Variable: objext

The standard object file suffix (normally `o').

Variable: pic_flag

Any additional compiler flags for building library object files.

Variable: postinstall_cmds
Variable: old_postinstall_cmds

Commands run after installing a shared or static library, respectively.

Variable: postuninstall_cmds
Variable: old_postuninstall_cmds

Commands run after uninstalling a shared or static library, respectively.

Variable: reload_cmds
Variable: reload_flag

Commands to create a reloadable object.

Variable: runpath_var

The environment variable that tells the linker which directories to hardcode in the resulting executable.

Variable: shlibpath_overrides_runpath

Indicates whether it is possible to override the hard-coded library search path of a program with an environment variable. If this is set to no, libtool may have to create two copies of a program in the build tree, one to be installed and one to be run in the build tree only. When each of these copies is created depends on the value of fast_install. The default value is `unknown', which is equivalent to `no'.

Variable: shlibpath_var

The environment variable that tells the dynamic linker where to find shared libraries.

Variable: soname_spec

The name coded into shared libraries, if different from the real name of the file.

Variable: striplib
Variable: old_striplib

Command to strip a shared (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 Install mode).

Variable: sys_lib_dlsearch_path_spec

Expression to get the run-time system library search path. Directories that appear in this list are never hard-coded into executables.

Variable: sys_lib_search_path_spec

Expression to get the compile-time system library search path. This variable is used by libtool when it has to test whether a certain library is shared or static. The directories listed in shlibpath_var are automatically appended to this list, every time libtool runs (i.e., not at configuration time), because some linkers use this variable to extend the library search path. Linker switches such as `-L' also augment the search path.

Variable: thread_safe_flag_spec

Linker flag (passed through the C compiler) used to generate thread-safe libraries.

Variable: version_type

The library version numbering type. One of `libtool', `freebsd-aout', `freebsd-elf', `irix', `linux', `osf', `sunos', `windows', or `none'.

Variable: whole_archive_flag_spec

Compiler flag to generate shared objects from convenience archives.

Variable: wl

The C compiler flag that allows libtool to pass a flag directly to the linker. Used as: ${wl}some-flag.

Variables ending in `_cmds' or `_eval' contain a `~'-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 libtool.

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

14.5 Cheap tricks

Here are a few tricks that you can use in order to make maintainership easier:

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] [ ? ]

This document was generated on July, 20 2009 using texi2html 1.76.