个人觉得的有用的文档，贴出来和大家分享

Shared library support for GNU

上一篇 / 下一篇 2006-09-28 19:39:33 / 天气: 晴朗 / 心情: 高兴 / 个人分类：linux

This file documents GNU Libtool 1.5.22

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.1 or any later version published by the Free Software Foundation; with the no Invariant Sections, with no Front-Cover Texts, and with no Back-Cover Texts. A copy of the license is included in the section entitled "GNU Free Documentation License".

Next: Introduction, Previous: (dir), Up: (dir)

Shared library support for GNU

This file documents GNU Libtool, a script that allows package developers to provide generic shared library support. This edition documents version 1.5.22.

SeeReporting bugs, for information on how to report problems with libtool.

Introduction: What the heck is libtool?
Libtool paradigm: How libtool's view of libraries is different.
Using libtool: Example of using libtool to build libraries.
Invoking libtool: Running thelibtoolscript.
Integrating libtool: Using libtool in your own packages.
Versioning: Using library interface versions.
Library tips: Tips for library interface design.
Inter-library dependencies: Libraries that depend on other libraries.
Dlopened modules:dlopening libtool-created libraries.
Using libltdl: Libtool's portabledlopenwrapper library.
Other languages: Using libtool without a C compiler.
Troubleshooting: When libtool doesn't work as advertised.
Maintaining: Information used by the libtool maintainer.
GNU Free Documentation License: License for this manual.
Index: Full index.

Introduction

Using libtool

Invokinglibtool

Integrating libtool with your package

Configuring libtool

Including libtool in your package

Library interface versions

Tips for interface design

Dlopened modules

Using libltdl

Using libtool with other languages

Troubleshooting

The libtool test suite

Maintenance notes for libtool

Porting libtool to new systems

Platform quirks

Next: Libtool paradigm, Previous: Top, Up: Top

1 Introduction

In the past, if a source code package developer wanted to take advantage of the power of shared libraries, he needed to write custom support code for each platform on which his package ran. He also had to design a configuration interface so that the package installer could choose what sort of libraries were built.

GNU Libtool simplifies the developer's job by encapsulating both the platform-specific dependencies, and the user interface, in a single script. GNU Libtool is designed so that the complete functionality of each host type is available via a generic interface, but nasty quirks are hidden from the programmer.

GNU Libtool's consistent interface is reassuring...users don't need to read obscure documentation in order to have their favorite source package build shared libraries. They just run your packageconfigurescript (or equivalent), and libtool does all the dirty work.

There are several examples throughout this document. All assume the same environment: we want to build a library,libhello, in a generic way.

libhellocould be a shared library, a static library, or both...whatever is available on the host system, as long as libtool has been ported to it.

This chapter explains the original design philosophy of libtool. Feel free to skip to the next chapter, unless you are interested in history, or want to write code to extend libtool in a consistent way.

Next: Issues, Up: Introduction

1.1 Motivation for writing libtool

Since early 1995, several different GNU developers have recognized the importance of having shared library support for their packages. The primary motivation for such a change is to encourage modularity and reuse of code (both conceptually and physically) in GNU programs.

Such a demand means that the way libraries are built in GNU packages needs to be general, to allow for any library type the package installer might want. The problem is compounded by the absence of a standard procedure for creating shared libraries on different platforms.

The following sections outline the major issues facing shared library support in GNU, and how shared library support could be standardized with libtool.

The following specifications were used in developing and evaluating this system:

The system must be as elegant as possible.
The system must be fully integrated with the GNU Autoconf and Automake utilities, so that it will be easy for GNU maintainers to use. However, the system must not require these tools, so that it can be used by non-GNU packages.
Portability to other (non-GNU) architectures and tools is desirable.

Next: Other implementations, Previous: Motivation, Up: Introduction

1.2 Implementation issues

The following issues need to be addressed in any reusable shared library system, specifically libtool:

The package installer should be able to control what sort of libraries are built.
It can be tricky to run dynamically linked programs whose libraries have not yet been installed.LD_LIBRARY_PATHmust be set properly (if it is supported), or programs fail to run.
The system must operate consistently even on hosts which don't support shared libraries.
The commands required to build shared libraries may differ wildly from host to host. These need to be determined at configure time in a consistent way.
It is not always obvious with which suffix a shared library should be installed. This makes it difficult forMakefilerules, since they generally assume that file names are the same from host to host.
The system needs a simple library version number abstraction, so that shared libraries can be upgraded in place. The programmer should be informed how to design the interfaces to the library to maximize binary compatibility.
The installMakefiletarget should warn the package installer to set the proper environment variables (LD_LIBRARY_PATHor equivalent), or runldconfig.

Next: Postmortem, Previous: Issues, Up: Introduction

1.3 Other implementations

Even before libtool was developed, many free software packages built and installed their own shared libraries. At first, these packages were examined to avoid reinventing existing features.

Now it is clear that none of these packages have documented the details of shared library systems that libtool requires. So, other packages have been more or less abandoned as influences.

Previous: Other implementations, Up: Introduction

1.4 A postmortem analysis of other implementations

In all fairness, each of the implementations that were examined do the job that they were intended to do, for a number of different host systems. However, none of these solutions seem to function well as a generalized, reusable component.

Most were too complex to use (much less modify) without understanding exactly what the implementation does, and they were generally not documented.

The main difficulty is that different vendors have different views of what libraries are, and none of the packages which were examined seemed to be confident enough to settle on a single paradigm that justworks.

Ideally, libtool would be a standard that would be implemented as series of extensions and modifications to existing library systems to make them work consistently. However, it is not an easy task to convince operating system developers to mend their evil ways, and people want to build shared libraries right now, even on buggy, broken, confused operating systems.

For this reason, libtool was designed as an independent shell script. It isolates the problems and inconsistencies in library building that plagueMakefilewriters by wrapping the compiler suite on different platforms with a consistent, powerful interface.

With luck, libtool will be useful to and used by the GNU community, and that the lessons that were learned in writing it will be taken up by designers of future library systems.

Next: Using libtool, Previous: Introduction, Up: Top

2 The libtool paradigm

At first, libtool was designed to support an arbitrary number of library object types. After libtool was ported to more platforms, a new paradigm gradually developed for describing the relationship between libraries and programs.

In summary, “libraries are programs with multiple entry points, and more formally defined interfaces.”

Version 0.7 of libtool was a complete redesign and rewrite of libtool to reflect this new paradigm. So far, it has proved to be successful: libtool is simpler and more useful than before.

The best way to introduce the libtool paradigm is to contrast it with the paradigm of existing library systems, with examples from each. It is a new way of thinking, so it may take a little time to absorb, but when you understand it, the world becomes simpler.

Next: Invoking libtool, Previous: Libtool paradigm, Up: Top

3 Using libtool

It makes little sense to talk about using libtool in your own packages until you have seen how it makes your life simpler. The examples in this chapter introduce the main features of libtool by comparing the standard library building procedure to libtool's operation on two different platforms:

a23: An Ultrix 4.2 platform with only static libraries.
burger: A NetBSD/i386 1.2 platform with shared libraries.

You can follow these examples on your own platform, using the preconfigured libtool script that was installed with libtool (seeConfiguring).

Source files for the following examples are taken from thedemosubdirectory of the libtool distribution. Assume that we are building a library,libhello, out of the filesfoo.candhello.c.

Note that thefoo.csource file uses thecosmath library function, which is usually found in the standalone math library, and not the C library (seeTrigonometric Functions (The GNU C Library Reference Manual)). So, we need to add-lmto the end of the link line whenever we linkfoo.oorfoo.lointo an executable or a library (seeInter-library dependencies).

The same rule applies whenever you use functions that don't appear in the standard C library...you need to add the appropriate-lnameflag to the end of the link line when you link against those objects.

After we have built that library, we want to create a program by linkingmain.oagainstlibhello.

Next: Linking libraries, Up: Using libtool

3.1 Creating object files

To create an object file from a source file, the compiler is invoked with the `-c' flag (and any other desired flags):

burger$gcc -g -O -c main.c
burger$

The above compiler command produces an object file,main.o, from the source filemain.c.

For most library systems, creating object files that become part of a static library is as simple as creating object files that are linked to form an executable:

burger$gcc -g -O -c foo.c
burger$gcc -g -O -c hello.c
burger$

Shared libraries, however, may only be built fromposition-independent code(PIC). So, special flags must be passed to the compiler to tell it to generate PIC rather than the standard position-dependent code.

Since this is a library implementation detail, libtool hides the complexity of PIC compiler flags by using separate library object files (which end in.loinstead of.o). On systems without shared libraries (or without special PIC compiler flags), these library object files are identical to “standard” object files.

To create library object files forfoo.candhello.c, simply invoke libtool with the standard compilation command as arguments (seeCompile mode):

a23$libtool --mode=compile gcc -g -O -c foo.c
gcc -g -O -c foo.c
echo timestamp > foo.lo
a23$libtool --mode=compile gcc -g -O -c hello.c
gcc -g -O -c hello.c
echo timestamp > hello.lo
a23$

Note that libtool creates two files for each invocation. The.lofile is a library object, which may be built into a shared library, and the.ofile is a standard object file. Ona23, the library objects are just timestamps, because only static libraries are supported.

On shared library systems, libtool automatically inserts the PIC generation flags into the compilation command, so that the library object and the standard object differ:

burger$libtool --mode=compile gcc -g -O -c foo.c
gcc -g -O -c -fPIC -DPIC foo.c
mv -f foo.o foo.lo
gcc -g -O -c foo.c >/dev/null 2>&1
burger$libtool --mode=compile gcc -g -O -c hello.c
gcc -g -O -c -fPIC -DPIC hello.c
mv -f hello.o hello.lo
gcc -g -O -c hello.c >/dev/null 2>&1
burger$

Notice that the second run of GCC has its output discarded. This is done so that compiler warnings aren't annoyingly duplicated.

Next: Linking executables, Previous: Creating object files, Up: Using libtool

3.2 linking libraries

Without libtool, the programmer would invoke thearcommand to create a static library:

burger$ar cru libhello.a hello.o foo.o
burger$

But of course, that would be too simple, so many systems require that you run theranlibcommand on the resulting library (to give it better karma, or something):

burger$ranlib libhello.a
burger$

It seems more natural to use the C compiler for this task, given libtool's “libraries are programs” approach. So, on platforms without shared libraries, libtool simply acts as a wrapper for the systemar(and possiblyranlib) commands.

Again, the libtool library name differs from the standard name (it has a.lasuffix instead of a.asuffix). The arguments to libtool are the same ones you would use to produce an executable namedlibhello.lawith your compiler (seeLink mode):

a23$libtool --mode=link gcc -g -O -o libhello.la foo.o hello.o
libtool: cannot build libtool library `libhello.la' from non-libtool \
objects
a23$

Aha! Libtool caught a common error...trying to build a library from standard objects instead of library objects. This doesn't matter for static libraries, but on shared library systems, it is of great importance.

So, let's try again, this time with the library object files. Remember also that we need to add-lmto the link command line becausefoo.cuses thecosmath library function (seeUsing libtool).

Another complication in building shared libraries is that we need to specify the path to the directory in which they (eventually) will be installed (in this case,/usr/local/lib)¹:

a23$libtool --mode=link gcc -g -O -o libhello.la foo.lo hello.lo \
-rpath /usr/local/lib -lm
mkdir .libs
ar cru .libs/libhello.a foo.o hello.o
ranlib .libs/libhello.a
creating libhello.la
a23$

Now, let's try the same trick on the shared library platform:

burger$libtool --mode=link gcc -g -O -o libhello.la foo.lo hello.lo \
-rpath /usr/local/lib -lm
mkdir .libs
ld -Bshareable -o .libs/libhello.so.0.0 foo.lo hello.lo -lm
ar cru .libs/libhello.a foo.o hello.o
ranlib .libs/libhello.a
creating libhello.la
burger$

Now that's significantly cooler...libtool just ran an obscureldcommand to create a shared library, as well as the static library.

Note how libtool creates extra files in the.libssubdirectory, rather than the current directory. This feature is to make it easier to clean up the build directory, and to help ensure that other programs fail horribly if you accidentally forget to use libtool when you should.

Next: Debugging executables, Previous: Linking libraries, Up: Using libtool

3.3 linking executables

If you choose at this point toinstallthe library (put it in a permanent location) before linking executables against it, then you don't need to use libtool to do the linking. Simply use the appropriate-Land-lflags to specify the library's location.

Some system linkers insist on encoding the full directory name of each shared library in the resulting executable. Libtool has to work around this misfeature by special magic to ensure that only permanent directory names are put into installed executables.

The importance of this bug must not be overlooked: it won't cause programs to crash in obvious ways. It creates a security hole, and possibly even worse, if you are modifying the library source code after you have installed the package, you will change the behaviour of the installed programs!

So, if you want to link programs against the library before you install it, you must use libtool to do the linking.

Here's the old way of linking against an uninstalled library:

burger$gcc -g -O -o hell.old main.o libhello.a -lm
burger$

Libtool's way is almost the same²(seeLink mode):

a23$libtool --mode=link gcc -g -O -o hell main.o libhello.la -lm
gcc -g -O -o hell main.o ./.libs/libhello.a -lm
a23$

That looks too simple to be true. All libtool did was transformlibhello.lato./.libs/libhello.a, but remember thata23has no shared libraries.

Onburgerthe situation is different:

burger$libtool --mode=link gcc -g -O -o hell main.o libhello.la -lm
gcc -g -O -o .libs/hell main.o -L./.libs -R/usr/local/lib -lhello -lm
creating hell
burger$

Now assumelibhello.lahad already been installed, and you want to link a new program with it. You could figure out where it lives by yourself, then run:

burger$gcc -g -O -o test test.o -L/usr/local/lib -lhello

However, unless/usr/local/libis in the standard library search path, you won't be able to runtest. However, if you use libtool to link the already-installed libtool library, it will do The Right Thing (TM) for you:

burger$libtool --mode=link gcc -g -O -o test \
test.o /usr/local/lib/libhello.la
gcc -g -O -o .libs/test test.o -Wl,--rpath
-Wl,/usr/local/lib /usr/local/lib/libhello.a -lm
creating test
burger$

Note that libtool added the necessary run-time path flag, as well as-lm, the library libhello.la depended upon. Nice, huh?

Since libtool created a wrapper script, you should use libtool to install it and debug it too. However, since the program does not depend on any uninstalled libtool library, it is probably usable even without the wrapper script. Libtool could probably be made smarter to avoid the creation of the wrapper script in this case, but this is left as an exercise for the reader.

Notice that the executable,hell, was actually created in the.libssubdirectory. Then, a wrapper script was created in the current directory.

On NetBSD 1.2, libtool encodes the installation directory oflibhello, by using the-R/usr/local/libcompiler flag. Then, the wrapper script guarantees that the executable finds the correct shared library (the one in./.libs) until it is properly installed.

Let's compare the two different programs:

burger$time ./hell.old
Welcome to GNU Hell!
** This is not GNU Hello.  There is no built-in mail reader. **
0.21 real         0.02 user         0.08 sys
burger$time ./hell
Welcome to GNU Hell!
** This is not GNU Hello.  There is no built-in mail reader. **
0.63 real         0.09 user         0.59 sys
burger$

The wrapper script takes significantly longer to execute, but at least the results are correct, even though the shared library hasn't been installed yet.

So, what about all the space savings that shared libraries are supposed to yield?

burger$ls -l hell.old libhello.a
-rwxr-xr-x  1 gord  gord  15481 Nov 14 12:11 hell.old
-rw-r--r--  1 gord  gord   4274 Nov 13 18:02 libhello.a
burger$ls -l .libs/hell .libs/libhello.*
-rwxr-xr-x  1 gord  gord  11647 Nov 14 12:10 .libs/hell
-rw-r--r--  1 gord  gord   4274 Nov 13 18:44 .libs/libhello.a
-rwxr-xr-x  1 gord  gord  12205 Nov 13 18:44 .libs/libhello.so.0.0
burger$

Well, that sucks. Maybe I should just scrap this project and take up basket weaving.

Actually, it just proves an important point: shared libraries incur overhead because of their (relative) complexity. In this situation, the price of being dynamic is eight kilobytes, and the payoff is about four kilobytes. So, having a sharedlibhellowon't be an advantage until we link it against at least a few more programs.

Next: Installing libraries, Previous: Linking executables, Up: Using libtool

3.4 Debugging executables

Ifhellwas a complicated program, you would certainly want to test and debug it before installing it on your system. In the above section, you saw how the libtool wrapper script makes it possible to run the program directly, but unfortunately, this mechanism interferes with the debugger:

burger$gdb hell
GDB is free software and you are welcome to distribute copies of it
under certain conditions; type "show copying" to see the conditions.
There is no warranty for GDB; type "show warranty" for details.
GDB 4.16 (i386-unknown-netbsd), (C) 1996 Free Software Foundation, Inc.

"hell": not in executable format: File format not recognized

(gdb)quit
burger$

Sad. It doesn't work because GDB doesn't know where the executable lives. So, let's try again, by invoking GDB directly on the executable:

burger$gdb .libs/hell
trick:/home/src/libtool/demo$ gdb .libs/hell
GDB is free software and you are welcome to distribute copies of it
under certain conditions; type "show copying" to see the conditions.
There is no warranty for GDB; type "show warranty" for details.
GDB 4.16 (i386-unknown-netbsd), (C) 1996 Free Software Foundation, Inc.
(gdb)break main
Breakpoint 1 at 0x8048547: file main.c, line 29.
(gdb)run
Starting program: /home/src/libtool/demo/.libs/hell
/home/src/libtool/demo/.libs/hell: can't load library 'libhello.so.2'

Program exited with code 020.
(gdb)quit
burger$

Argh. Now GDB complains because it cannot find the shared library thathellis linked against. So, we must use libtool in order to properly set the library path and run the debugger. Fortunately, we can forget all about the.libsdirectory, and just run it on the executable wrapper (seeExecute mode):

burger$libtool --mode=execute gdb hell
GDB is free software and you are welcome to distribute copies of it
under certain conditions; type "show copying" to see the conditions.
There is no warranty for GDB; type "show warranty" for details.
GDB 4.16 (i386-unknown-netbsd), (C) 1996 Free Software Foundation, Inc.
(gdb)break main
Breakpoint 1 at 0x8048547: file main.c, line 29.
(gdb)run
Starting program: /home/src/libtool/demo/.libs/hell

Breakpoint 1, main (argc=1, argv=0xbffffc40) at main.c:29
29	  printf ("Welcome to GNU Hell!\n");
(gdb)quit
The program is running.  Quit anyway (and kill it)? (y or n)y
burger$

Next: Installing executables, Previous: Debugging executables, Up: Using libtool

3.5 Installing libraries

Installing libraries on a non-libtool system is quite straightforward...just copy them into place:³

burger$su
Password:********
burger#cp libhello.a /usr/local/lib/libhello.a
burger#

Oops, don't forget theranlibcommand:

burger#ranlib /usr/local/lib/libhello.a
burger#

Libtool installation is quite simple, as well. Just use theinstallorcpcommand that you normally would (seeInstall mode):

a23#libtool --mode=install cp libhello.la /usr/local/lib/libhello.la
cp libhello.la /usr/local/lib/libhello.la
cp .libs/libhello.a /usr/local/lib/libhello.a
ranlib /usr/local/lib/libhello.a
a23#

Note that the libtool librarylibhello.lais also installed, to help libtool with uninstallation (seeUninstall mode) and linking (seeLinking executables) and to help programs with dlopening (seeDlopened modules).

Here is the shared library example:

burger#libtool --mode=install install -c libhello.la \
/usr/local/lib/libhello.la
install -c .libs/libhello.so.0.0 /usr/local/lib/libhello.so.0.0
install -c libhello.la /usr/local/lib/libhello.la
install -c .libs/libhello.a /usr/local/lib/libhello.a
ranlib /usr/local/lib/libhello.a
burger#

It is safe to specify the-s(strip symbols) flag if you use a BSD-compatible install program when installing libraries. Libtool will either ignore the-sflag, or will run a program that will strip only debugging and compiler symbols from the library.

Once the libraries have been put in place, there may be some additional configuration that you need to do before using them. First, you must make sure that where the library is installed actually agrees with the-rpathflag you used to build it.

Then, runninglibtool -n --mode=finishlibdircan give you further hints on what to do (seeFinish mode):

burger#libtool -n --mode=finish /usr/local/lib
PATH="$PATH:/sbin" ldconfig -m /usr/local/lib
-----------------------------------------------------------------
Libraries have been installed in:
/usr/local/lib

To link against installed libraries in a given directory, LIBDIR,
you must use the `-LLIBDIR' flag during linking.

You will also need to do one of the following:
- add LIBDIR to the `LD_LIBRARY_PATH' environment variable
during execution
- add LIBDIR to the `LD_RUN_PATH' environment variable
during linking
- use the `-RLIBDIR' linker flag

See any operating system documentation about shared libraries for
more information, such as the ld and ld.so manual pages.
-----------------------------------------------------------------
burger#

After you have completed these steps, you can go on to begin using the installed libraries. You may also install any executables that depend on libraries you created.

Next: Static libraries, Previous: Installing libraries, Up: Using libtool

3.6 Installing executables

If you used libtool to link any executables against uninstalled libtool libraries (seeLinking executables), you need to use libtool to install the executables after the libraries have been installed (seeInstalling libraries).

So, for our Ultrix example, we would run:

a23# libtool install -c hell /usr/local/bin/hell
install -c hell /usr/local/bin/hell
a23#

On shared library systems, libtool just ignores the wrapper script and installs the correct binary:

burger# libtool install -c hell /usr/local/bin/hell
install -c .libs/hell /usr/local/bin/hell
burger#

Previous: Installing executables, Up: Using libtool

3.7 linking static libraries

Why return toarandranlibsilliness when you've had a taste of libtool? Well, sometimes it is desirable to create a static archive that can never be shared. The most frequent case is when you have a set of object files that you use to build several different programs. You can create a “convenience library” out of those objects, and link programs with the library, instead of listing all object files for every program. This technique is often used to overcome GNU automake's lack of support for linking object files built from sources in other directories, because it supports linking with libraries from other directories. This limitation applies to GNU automake up to release 1.4; newer releases should support sources in other directories.

If you just want to link this convenience library into programs, then you could just ignore libtool entirely, and use the oldarandranlibcommands (or the corresponding GNU automake_LIBRARIESrules). You can even install a convenience library (but you probably don't want to) using libtool:

burger$libtool --mode=install ./install-sh -c libhello.a \
/local/lib/libhello.a
./install-sh -c libhello.a /local/lib/libhello.a
ranlib /local/lib/libhello.a
burger$

Using libtool for static library installation protects your library from being accidentally stripped (if the installer used the-sflag), as well as automatically running the correctranlibcommand.

But libtool libraries are more than just collections of object files: they can also carry library dependency information, which old archives do not. If you want to create a libtool static convenience library, you can omit the-rpathflag and use-staticto indicate that you're only interested in a static library. When you link a program with such a library, libtool will actually link all object files and dependency libraries into the program.

If you omit both-rpathand-static, libtool will create a convenience library that can be used to create other libtool libraries, even shared ones. Just like in the static case, the library behaves as an alias to a set of object files and dependency libraries, but in this case the object files are suitable for inclusion in shared libraries. But be careful not to link a single convenience library, directly or indirectly, into a single program or library, otherwise you may get errors about symbol redefinitions.

When GNU automake is used, you should usenoinst_LTLIBRARIESinstead oflib_LTLIBRARIESfor convenience libraries, so that the-rpathoption is not passed when they are linked.

As a rule of thumb, link a libtool convenience library into at most one libtool library, and never into a program, and link libtool static convenience libraries only into programs, and only if you need to carry library dependency information to the user of the static convenience library.

Another common situation where static linking is desirable is in creating a standalone binary. Use libtool to do the linking and add the-all-staticflag.

Next: Integrating libtool, Previous: Using libtool, Up: Top

4 Invoking`libtool`

Thelibtoolprogram has the following synopsis:

libtool [option]... [mode-arg]...

and accepts the following options:

--config

Display libtool configuration variables and exit.

--debug

Dump a trace of shell script execution to standard output. This produces a lot of output, so you may wish to pipe it toless(ormore) or redirect to a file.

-n

--dry-run

Don't create, modify, or delete any files, just show what commands would be executed by libtool.

--features

Display basic configuration options. This provides a way for packages to determine whether shared or static libraries will be built.

--preserve-dup-deps

Do not remove duplicate dependencies in libraries. When building packages with static libraries, the libraries may depend circularly on each other (shared libs can too, but for those it doesn't matter), so there are situations, where -la -lb -la is required, and the second -la may not be stripped or the link will fail. In cases where these duplications are required, this option will preserve them, only stripping the libraries that libtool knows it can safely.

--finish

Same as--mode=finish.

--help

Display a help message and exit. If--mode=modeis specified, then detailed help formodeis displayed.

--mode=mode

Usemodeas the operation mode. If not specified, an attempt is made to infer the operation mode from themode-args. Not specifying themodeis currently deprecated, as there are too many situations where it is not possible to guess. Future versions of Libtool will require thatmodebe explicitly set.

modemust be set to one of the following:

compile: Compile a source file into a libtool object.
execute: Automatically set the library path so that another program can use uninstalled libtool-generated programs or libraries.
finish: Complete the installation of libtool libraries on the system.
install: Install libraries or executables.
link: Create a library or an executable.
uninstall: Delete installed libraries or executables.
clean: Delete uninstalled libraries or executables.

--version

Print libtool version information and exit.

Themode-argsare a variable number of arguments, depending on the selected operation mode. In general, eachmode-argis interpreted by programs libtool invokes, rather than libtool itself.

Next: Link mode, Up: Invoking libtool

4.1 Compile mode

Forcompilemode,mode-argsis a compiler command to be used in creating a `standard' object file. These arguments should begin with the name of the C compiler, and contain the-ccompiler flag so that only an object file is created.

Libtool determines the name of the output file by removing the directory component from the source file name, then substituting the source code suffix (e.g..cfor C source code) with the library object suffix,.lo.

If shared libraries are being built, any necessary PIC generation flags are substituted into the compilation command. You can pass link specific flags to the compiler driver using-XCClinkerflagor pass linker flags with-Wl,flagand-Xl

导入论坛收藏分享给好友管理举报

TAG: 电脑网络 linux

查看全部评论