* 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 @file{libtool}:: Running the @file{libtool} script.
+* Invoking libtool:: Running the @file{libtool} script.
* Integrating Libtool:: Using libtool in your own packages.
* Versioning:: Using library interface versions.
* Library Tips:: Tips for library interface design.
* Configuring:: Configuring libtool for a host system.
* Distributing:: What files to distribute with your package.
+Configuring Libtool
+
+* Invoking ltconfig::
+* ltconfig Example::
+* AM_PROG_LIBTOOL::
+
Including Libtool with Your Package
-* Invoking @file{libtoolize}:: @file{libtoolize} command line options.
+* Invoking libtoolize:: @file{libtoolize} command line options.
Library Interface Versions
* Interfaces:: What are library interfaces?
* Libtool Versioning:: Libtool's versioning system.
-* Version Files:: How libtool tracks library versions.
-* Updating @file{libinfo}:: Keeping a library version file up-to-date.
+* Updating Version Info:: Changing version information before releases.
+
+Tips for Interface Design
+
+* C Header Files:: How to write portable include files.
@end menu
@end ifinfo
non-GNU packages.
@item
-Portablility to other (non-GNU) architectures and tools is desirable.
+Portability to other (non-GNU) architectures and tools is desirable.
@end enumerate
@node Issues, Other Implementations, Motivation, Introduction
a consistent way.
@item
-Some operating systems do not support shared object version numbers, and
-it is not obvious with which suffix a shared object should be installed.
-This makes it difficult for Makefile rules, since they generally assume
-that filenames are the same from host to host.
-
-@item
-Programmers need to be aware of what assumptions they are allowed to
-make. Library names will need to be carefully chosen (to avoid name
-clashes), binary compatibility needs to be accounted for,
+It is not always obvious with which suffix a shared object should be
+installed. This makes it difficult for Makefile rules, since they
+generally assume that filenames are the same from host to host.
@item
The system needs a simple library version number abstraction, so that
is a new way of thinking, so it may take a little time to absorb, but
when you understand it the world gets simpler.
-@node Using Libtool, Invoking @file{libtool}, Libtool Paradigm, Top
+@node Using Libtool, Invoking libtool, Libtool Paradigm, Top
@comment node-name, next, previous, up
@chapter Using Libtool
@menu
* Creating Object Files:: Compiling object files for libraries.
-* Linking Libraries::
+* Linking Libraries:: Creating libraries from object files.
* Linking Executables:: Linking object files against libtool libraries.
* Installing Libraries:: Making libraries available to users.
* Installing Executables:: Making programs available to users.
creating a standalone binary. Use libtool to do the linking and add the
@samp{-static} flag.
-@node Invoking @file{libtool}, Integrating Libtool, Using Libtool, Top
+@node Invoking libtool, Integrating Libtool, Using Libtool, Top
@comment node-name, next, previous, up
@chapter Invoking @file{libtool}
* Uninstall Mode:: Removing executables and libraries.
@end menu
-@node Compile Mode, Link Mode, Invoking @file{libtool}, Invoking @file{libtool}
+@node Compile Mode, Link Mode, Invoking libtool, Invoking libtool
@comment node-name, next, previous, up
@section Compile Mode
If shared libraries are being built, any necessary PIC generation flags
are substituted into the compilation command.
-@node Link Mode, Install Mode, Compile Mode, Invoking @file{libtool}
+@node Link Mode, Install Mode, Compile Mode, Invoking libtool
@comment node-name, next, previous, up
@section Link Mode
shared libraries. If @var{output-file} is a library, then only create a
static library.
-@item -version-file @var{verfile}
-If @var{output-file} is a library, then search for library versioning
-information in @var{verfile}.
+@item -version-info @var{current}[:@var{revision}[:@var{age}]]
+If @var{output-file} is a libtool library, use library version
+information @var{current}, @var{revision}, and @var{age} to build it.
+If not specified, each of these variables defaults to 0
+(@pxref{Versioning}).
@end table
If the @var{output-file} ends in `.la', then a libtool library is
Otherwise, an executable program is created.
-@node Install Mode, Finish Mode, Link Mode, Invoking @file{libtool}
+@node Install Mode, Finish Mode, Link Mode, Invoking libtool
@comment node-name, next, previous, up
@section Install Mode
The command is run, and any necessary unprivileged post-installation
commands are also completed.
-@node Finish Mode, Uninstall Mode, Install Mode, Invoking @file{libtool}
+@node Finish Mode, Uninstall Mode, Install Mode, Invoking libtool
@comment node-name, next, previous, up
@section Finish Mode
Running this command may require superuser privileges, so the
@samp{--dry-run} option may be useful.
-@node Uninstall Mode, , Finish Mode, Invoking @file{libtool}
+@node Uninstall Mode, , Finish Mode, Invoking libtool
@comment node-name, next, previous, up
@section Uninstall Mode
The remaning @var{mode-args} are either flags for the deletion program
(beginning with a `-'), or the names of files to delete.
-@node Integrating Libtool, Versioning, Invoking @file{libtool}, Top
+@node Integrating Libtool, Versioning, Invoking libtool, Top
@comment node-name, next, previous, up
@chapter Integrating Libtool with Your Own Packages
@samp{-static}.
Building a libtool library is almost as trivial@dots{} note the use of
-@samp{libhell_la_LDFLAGS} to pass the @samp{-version-file}
+@samp{libhell_la_LDFLAGS} to pass the @samp{-version-info}
(@pxref{Versioning}) and @samp{-rpath} options to libtool:
@example
# Build a libtool library, libhell.la for installation in libdir.
lib_PROGRAMS = libhell.la
libhell_la_SOURCES = hello.c foo.c
-libhell_la_LDFLAGS = -version-file $(srcdir)/libinfo -rpath $(libdir)
+libhell_la_LDFLAGS = -version-info 3:12:1 -rpath $(libdir)
@end example
@node Configuring, Distributing, Using Automake, Integrating Libtool
@comment node-name, next, previous, up
@section Configuring Libtool
-FIXME
-Description of what it means to configure libtool. ltconfig synopsis
-description of AM_PROG_LIBTOOL, how to add to aclocal
+Libtool requires intimate knowledge of your compiler suite and operating
+system in order to be able to create shared libraries and link against
+them properly. When you install the libtool distribution, a
+system-specific libtool script is installed into your binary directory.
+
+However, when you distribute libtool with your own packages
+(@pxref{Distributing}), you do not always know which compiler suite and
+operating system are used to compile your package.
+
+For this reason, libtool must be @dfn{configured} before it can be
+used. This idea should be familiar to anybody who has used a GNU
+@file{configure} script. @file{configure} runs a number of tests for
+system features, then generates the @file{Makefiles} (and possibly a
+@file{config.h} header file), after which you can run @file{make} and
+build the package.
+
+Libtool has its own equivalent to the @file{configure} script,
+@file{ltconfig}.
+
+@menu
+* Invoking ltconfig:: @file{ltconfig} command line options.
+* ltconfig Example:: Manually configuring a @file{libtool}.
+* AM_PROG_LIBTOOL:: Configuring @file{libtool} in @file{configure.in}.
+@end menu
+
+@node Invoking ltconfig, ltconfig Example, Configuring, Configuring
+@comment node-name, next, previous, up
+@subsection Invoking @file{ltconfig}
+
+@file{ltconfig} runs a series of configuration tests, then creates a
+system-specific @file{libtool} in the current directory. The
+@file{ltconfig} program has the following synopsis:
+
+@example
+ltconfig [@var{option}]@dots{} @var{ltmain} [@var{host}]
+@end example
+
+@noindent
+and accepts the following options:
+
+@table @samp
+@item --disable-shared
+Create a @file{libtool} that only builds static libraries.
+
+@item --help
+Display a help message and exit.
+
+@item --no-verify
+Do not use @file{config.sub} to verify that @var{host} is a valid
+canonical host system name.
+
+@item --quiet
+@item --silent
+Do not print informational messages when running configuration tests.
+
+@item --srcdir=@var{dir}
+Look for @file{config.guess} and @file{config.sub} in @var{dir}.
+
+@item --version
+Print @file{ltconfig} version information and exit.
+
+@item --with-gcc
+Assume that the GNU C compiler will be used when invoking the created
+@file{libtool} to compile and link object files.
+@end table
+
+@var{ltmain} is the @file{ltmain.sh} shell script fragment that provides
+the basic libtool functionality (@pxref{Distributing}).
+
+@var{host} is the canonical host system name, which by default is
+guessed by running @file{config.guess}.
+
+@file{ltconfig} also recognizes the following environment variables:
+
+@table @var
+@item CC
+The C compiler that will be used by the generated @file{libtool}.
+
+@item CFLAGS
+Compiler flags used to generate standard object files.
+
+@item LD
+The system linker to use (if the generated @file{libtool} requires one).
+
+@item RANLIB
+Program to use rather than checking for @file{ranlib}.
+@end table
+
+@node ltconfig Example, AM_PROG_LIBTOOL, Invoking ltconfig, Configuring
+@comment node-name, next, previous, up
+@subsection Using @file{ltconfig}
+
+Here is a simple example of using @file{ltconfig} to configure libtool
+on my NetBSD/i386 1.2 system:
+
+@example
+burger$ @kbd{./ltconfig ltmain.sh}
+checking host system type... i386-unknown-netbsd1.2
+checking for ranlib... ranlib
+checking for library strip program... strip -x
+checking for gcc... gcc
+checking whether we are using GNU C... yes
+checking for gcc option to produce PIC... -fPIC -DPIC
+checking for gcc option to statically link programs... -static
+checking if ld is GNU ld... no
+checking if ld supports shared libraries... yes
+checking dynamic linker characteristics... netbsd1.2 ld.so
+checking if libtool supports shared libraries... yes
+checking whether to build shared libraries... yes
+creating libtool
+burger$
+@end example
+
+This example shows how to configure @file{libtool} for cross-compiling
+to a i486 GNU/Hurd 0.1 system (assuming compiler tools reside in
+@file{/local/i486-gnu/bin}):
+
+@example
+burger$ export PATH=/local/i486-gnu/bin:$PATH
+burger$ ./ltconfig ltmain.sh i486-gnu0.1
+checking host system type... i486-unknown-gnu0.1
+checking for ranlib... ranlib
+checking for library strip program... strip -x
+checking for gcc... gcc
+checking whether we are using GNU C... yes
+checking for gcc option to produce PIC... -fPIC -DPIC
+checking for gcc option to statically link programs... -static
+checking if ld is GNU ld... yes
+checking if GNU ld supports shared libraries... yes
+checking dynamic linker characteristics... gnu0.1 ld.so
+checking if libtool supports shared libraries... yes
+checking whether to build shared libraries... yes
+creating libtool
+burger$
+@end example
+
+@node AM_PROG_LIBTOOL, , ltconfig Example, Configuring
+@comment node-name, next, previous, up
+@subsection The @code{AM_PROG_LIBTOOL} macro
+
+If you are using GNU Autoconf (or Automake), you should add a call to
+@code{AM_PROG_LIBTOOL} to your @file{configure.in} file. This macro
+offers seamless integration between the @file{configure} script and
+@file{ltconfig}.
+
+@code{AM_PROG_LIBTOOL} also adds support for the @samp{--enable-shared}
+and @samp{--disable-shared} @file{configure} flags.
+
+When you invoke the @file{libtoolize} program (@pxref{Invoking
+libtoolize}), it will tell you where to find a definition of
+@file{AM_PROG_LIBTOOL}. If you use Automake, the @file{aclocal} program
+will automatically add @file{AM_PROG_LIBTOOL} support to your
+@file{configure} script.
@node Distributing, , Configuring, Integrating Libtool
@comment node-name, next, previous, up
use the @file{libtoolize} program.
@menu
-* Invoking @file{libtoolize}:: @file{libtoolize} command line options.
+* Invoking libtoolize:: @file{libtoolize} command line options.
@end menu
-@node Invoking @file{libtoolize}, , Distributing, Distributing
+@node Invoking libtoolize, , Distributing, Distributing
@comment node-name, next, previous, up
@subsection Invoking @file{libtoolize}
@menu
* Interfaces:: What are library interfaces?
* Libtool Versioning:: Libtool's versioning system.
-* Version Files:: How libtool tracks library versions.
-* Updating @file{libinfo}:: Keeping a library version file up-to-date.
+* Updating Version Info:: Changing version information before releases.
@end menu
@node Interfaces, Libtool Versioning, Versioning, Versioning
Note that static functions do not count as interfaces, because they are
not directly available to the user of the library.
-@node Libtool Versioning, Version Files, Interfaces, Versioning
+@node Libtool Versioning, Updating Version Info, Interfaces, Versioning
@comment node-name, next, previous, up
@section Libtool's Versioning System
then the dynamic linker chooses the library with the greater
@var{revision} number.
-@node Version Files, Updating @file{libinfo}, Libtool Versioning, Versioning
+@node Updating Version Info, , Libtool Versioning, Versioning
@comment node-name, next, previous, up
-@section Version Files
+@section Updating the Library Version Information
-By default, libtool creates libraries with @var{current}, @var{age}, and
-@var{revision} all set to 0.
+If you want to use libtool's versioning system, then you must specify
+the version information to libtool using the @samp{-version-info} flag
+during link mode (@pxref{Link Mode}).
-If you want to use libtool's versioning system, then you must specify a
-file that contains version information for the library you are creating,
-using the @samp{-version-file} flag during link mode (@pxref{Link
-Mode}).
+This flag accepts an argument of the form
+@samp{@var{current}[:@var{revision}[:@var{age}]]}. So, passing
+@samp{-version-info 3:12:1} sets @var{current} to 3, @var{revision} to
+12, and @var{age} to 1.
-By convention, the name of the version file is @file{libinfo}, though it
-can be any file you want.
+If either @var{revision} or @var{age} are omitted, they default to 0.
+Also note that @var{age} must be less than or equal to the @var{current}
+interface number.
-Here are the contents of the @file{libinfo} file from the @file{demo}
-subdirectory of the libtool distribution:
-
-@example
-# libinfo - used by libtool for library version information
-#
-# Comments begin with a hash sign.
-#
-# Each non-comment line has the following format:
-# libNAME CURRENT AGE REVISION
-libhell 3 1 12
-@end example
-
-So, this file tells libtool that @file{libhello} supports interfaces 2
-and 3, and that it should be used instead of libraries with revisions
-less than 12.
-
-@node Updating @file{libinfo}, , Version Files, Versioning
-@comment node-name, next, previous, up
-@section Updating the @file{libinfo} File
-
-Here are a set of rules to help you update your library version file:
+Here are a set of rules to help you update your library version
+information:
@enumerate 1
@item
-Start with a version file that contains only:
-
-@example
-libNAME 0 0 0
-@end example
-
-@noindent
-for each libtool library @file{lib@var{name}}.
+Start with version information of @samp{0:0:0} for each libtool library.
@item
-Update the version file only immediately before a public release of your
-software. More frequent updates are unnecessary, and only guarantee
-that the current interface number gets larger faster.
+Update the version information only immediately before a public release
+of your software. More frequent updates are unnecessary, and only
+guarantee that the current interface number gets larger faster.
@item
If the library source code has changed at all since the last update,
-then increment @var{revision}.
+then increment @var{revision} (@samp{@var{c}:@var{r}:@var{a}} becomes
+@samp{@var{c}:@var{r+1}:@var{a}}).
@item
If any interfaces have been added, removed, or changed since the last
@emph{NEVER} try to set library version numbers so that they correspond
to the release of the package that you are making. This is an abuse
-that only fosters misunderstanding of the purpose of library versions,
-and you would be better off not using a @file{libinfo} file at all.
+that only fosters misunderstanding of the purpose of library versions.
@node Library Tips, Modifying, Versioning, Top
@comment node-name, next, previous, up
If you are careful to document each of your library's global functions
and variables in header files, and include them in your source files,
then the compiler will let you know if you make any interface changes by
-accident.
+accident (@pxref{C Header Files}).
@item Use the @code{static} keyword whenever possible
The fewer global functions your library has, the more flexibility you'll
aren't interface changes.
@end table
+@menu
+* C Header Files:: How to write portable include files.
+@end menu
+
+@node C Header Files, , Library Tips, Library Tips
+@comment node-name, next, previous, up
+@section Writing C Header Files
+
+Writing portable C header files can be difficult, since they may be read
+by different types of compilers:
+
+@table @asis
+@item C++ compilers
+C++ compilers require that functions be declared with full prototypes,
+since C++ is more strongly typed than C. C functions and variables also
+need to be declared with the @code{extern "C"} directive, so that the
+names aren't mangled.
+
+@item ANSI C compilers
+ANSI C compilers are not as strict as C++ compilers, but functions
+should be prototyped to avoid unnecessary warnings when the header file
+is @code{#include}d.
+
+@item non-ANSI C compilers
+Non-ANSI compilers will report errors if functions are prototyped.
+@end table
+
+These complications mean that your library interface headers must use
+some C preprocessor magic in order to be usable by each of the above
+compilers.
+
+@file{foo.h} in the @file{demo} subdirectory of the libtool distribution
+serves as an example for how to write a header file that can be
+safely installed in a system directory.
+
+Here are the relevant portions of that file:
+
+@example
+/* __BEGIN_DECLS should be used at the beginning of your C declarations,
+ so that C++ compilers don't mangle their names. */
+#ifndef __BEGIN_DECLS
+# ifdef __cplusplus
+# define __BEGIN_DECLS extern "C" @{
+# else
+# define __BEGIN_DECLS
+# endif
+#endif
+#ifndef __END_DECLS
+# ifdef __cplusplus
+# define __END_DECLS @};
+# else
+# define __END_DECLS
+# endif
+#endif
+
+/* __P is a macro used to wrap function prototypes, so that compilers that
+ don't understand ANSI C prototypes still work, and ANSI C compilers can
+ issue warnings about type mismatches. */
+#ifndef __P
+# if defined (__STDC__) || defined (_AIX) \
+ || (defined (__mips) && defined (_SYSTYPE_SVR4)) \
+ || defined(WIN32) || defined(__cplusplus)
+# define __P(protos) protos
+# else
+# define __P(protos) ()
+# endif
+#endif
+@end example
+
+These macros are used in @file{foo.h} as follows:
+
+@example
+#ifdef _FOO_H_
+#define _FOO_H_
+
+/* The above macro definitions. */
+@dots{}
+
+__BEGIN_DECLS
+int foo __P((void));
+int hello __P((void));
+__END_DECLS
+
+#endif /* !_FOO_H_ */
+@end example
+
+Note that the @file{#ifdef _FOO_H_} prevents the body of @file{foo.h}
+from being read more than once in a given compilation, which prevents
+multiple definition errors.
+
+Feel free to copy the definitions of @code{__P}, @code{__BEGIN_DECLS},
+and @code{__END_DECLS} into your own headers. Then, you may use them to
+create header files that are valid for C++, ANSI, and non-ANSI
+compilers.
+
@node Modifying, Index, Library Tips, Top
@comment node-name, next, previous, up
@chapter Modifying Libtool
done
# Get the name of the library object.
- libobj=`echo "$srcfile" | sed -e 's%^.*/%%' -e 's/\.c$/.lo/'`
+ libobj=`echo "$srcfile" | sed -e 's%^.*/%%; s/\.[Sc]$/.lo/'`
case $libobj in
*.lo) obj=`echo "$libobj" | sed -e 's/\.lo$/.o/'` ;;
*)
vinfo=
- # Maybe set the library names to libNAME_p.a if we are doing profiling.
- if echo " $@ " | egrep "[ ]$profile_flag_pattern[ ]" > /dev/null 2>&1; then
- suffix=p
- else
- suffix=
- fi
+# FIXME Maybe set the library names to libNAME_p.a if we are doing profiling.
+# if echo " $@ " | egrep "[ ]$profile_flag_pattern[ ]" > /dev/null 2>&1; then
+# suffix=p
+# else
+# suffix=
+# fi
for arg
do
# Automake's ansi2knr support code uses the "._o" and ".l_o" object
# suffixes.
- *.o | *._o)
+ *.o | *._o | *.a)
# A standard object.
objs="$objs $arg"
;;
test "$dir" = "$arg" && dir=.
file=`echo "$arg" | sed 's%^.*/%%'`
- case "$file" in
- lib?*.la)
- link_against_libtool_libs="$link_against_libtool_libs $arg"
- if test "$build_libtool_libs" = yes; then
- # Specify the library as -lNAME.
- carg="-l`echo "$file" | sed 's/lib\(..*\)\.la$/\1/'`"
- farg="$carg"
-
- if test -n "$shlibpath_var"; then
- # Make sure the rpath contains only unique directories.
- case "$temp_rpath " in
- "* $dir *") ;;
- *) temp_rpath="$temp_rpath $dir" ;;
- esac
- fi
-
- # Check to see that this really is a libtool archive.
- if egrep "^# Generated by $PROGRAM" $arg >/dev/null 2>&1; then :
- else
- echo "$progname: \`$arg' is not a valid libtool archive" 1>&2
- exit 1
- fi
+ link_against_libtool_libs="$link_against_libtool_libs $arg"
+ if test "$build_libtool_libs" = yes; then
+ # Specify the library as -lNAME.
+ carg="-l`echo "$file" | sed 's/lib\(..*\)\.la$/\1/'`"
+ farg="$carg"
+
+ if test -n "$shlibpath_var"; then
+ # Make sure the rpath contains only unique directories.
+ case "$temp_rpath " in
+ "* $dir *") ;;
+ *) temp_rpath="$temp_rpath $dir" ;;
+ esac
+ fi
- libdir=
- . $dir/$file
+ # Check to see that this really is a libtool archive.
+ if egrep "^# Generated by $PROGRAM" $arg >/dev/null 2>&1; then :
+ else
+ echo "$progname: \`$arg' is not a valid libtool archive" 1>&2
+ exit 1
+ fi
- if test -z "$libdir"; then
- echo "$progname: \`$arg' contains no -rpath information" 1>&2
- exit 1
- fi
+ libdir=
+ . $dir/$file
- if test -n "$link_rpath_flag"; then
- carg="`eval echo \"$link_rpath_flag\"` $carg"
- farg="$carg"
- fi
+ if test -z "$libdir"; then
+ echo "$progname: \`$arg' contains no -rpath information" 1>&2
+ exit 1
+ fi
- if test "$hardcode_minus_L" != yes; then
- # Just give the right -L directory flag.
- carg="-L$dir/$objdir $carg"
-
- elif test "$hardcode_shlibpath_var" = yes; then
- # Give an absolute path to the library.
- case "$dir" in
- /*) absdir="$dir" ;;
- *)
- absdir=`cd $dir && pwd`
- if test -z "$absdir"; then
- echo "$progname: cannot determine absolute pathname of \`$dir'" 1>&2
- exit 1
- fi
- ;;
- esac
- carg="-L$absdir/$objdir $carg"
- farg="-L$libdir $farg"
- fi
- else
- # Transform directly to old archives if we don't build new libraries.
- carg="$dir/$objdir/`echo "$file" | sed 's/\.la$/.a/'`"
+ if test -n "$link_rpath_flag"; then
+ carg="`eval echo \"$link_rpath_flag\"` $carg"
farg="$carg"
fi
- ;;
- *)
- echo "$progname: improperly formed library name \`$arg' (not libNAME.la)" 1>&2
- echo "$help"
- exit 1
- ;;
- esac
+
+ if test "$hardcode_minus_L" != yes; then
+ # Just give the right -L directory flag.
+ carg="-L$dir/$objdir $carg"
+
+ elif test "$hardcode_shlibpath_var" = yes; then
+ # Give an absolute path to the library.
+ case "$dir" in
+ /*) absdir="$dir" ;;
+ *)
+ absdir=`cd $dir && pwd`
+ if test -z "$absdir"; then
+ echo "$progname: cannot determine absolute pathname of \`$dir'" 1>&2
+ exit 1
+ fi
+ ;;
+ esac
+ carg="-L$absdir/$objdir $carg"
+ farg="-L$libdir $farg"
+ fi
+ else
+ # Transform directly to old archives if we don't build new libraries.
+ carg="$dir/$objdir/`echo "$file" | sed 's/\.la$/.a/'`"
+ farg="$carg"
+ fi
;;
*)
fi
;;
- lib?*.la)
+ *.la)
libname=`echo "$output" | sed 's/\.la$//'`
if test -n "$objs"; then
linknames="$linknames $objdir/$link"
done
+ # Use standard objects if they are PIC.
+ test -z "$pic_flag" && libobjs=`echo "$libobjs " | sed 's/\.lo /.o /g; s/\.l_o /._o /g; s/ $//g'`
+
# Do each of the archive commands.
cmds=`eval echo \"$archive_cmds\"`
IFS="${IFS= }"; save_ifs="$IFS"; IFS=';'
fi
;;
- *.la)
- echo "$progname: improperly formed library name \`$arg' (not libNAME.la)" 1>&2
- echo "$help"
- exit 1
- ;;
-
*.lo | *.o)
if test -n "$link_against_libtool_libs"; then
echo "$progname: error: cannot link libtool libraries into reloadable objects" 1>&2
fi
if test -n "$libobjs"; then
- # FIXME - transform all the library objects into standard objects.
- echo "$progname: warning: library object files should not be used to build programs" 1>&2
+ # Transform all the library objects into standard objects.
+ compile_command=`echo "$compile_command " | sed 's/\.lo /.o /g; s/\.l_o /._o /g; s/ $//g'`
+
fi
if test -z "$link_against_libtool_libs" || test "$build_libtool_libs" != yes; then
esac
done
- # Install any profiled libraries, too.
- newfiles=
- for file in $staticlibs; do
- newfiles="$newfiles $file"
- pfile=`echo "$file" | sed 's/\.a$/_p.a/'`
- test -f "$pfile" && newfiles="$newfiles $pfile"
- done
- staticlibs="$newfiles"
+# FIXME Install any profiled libraries, too.
+# newfiles=
+# for file in $staticlibs; do
+# newfiles="$newfiles $file"
+# pfile=`echo "$file" | sed 's/\.a$/_p.a/'`
+# test -f "$pfile" && newfiles="$newfiles $pfile"
+# done
+# staticlibs="$newfiles"
for file in $staticlibs; do
name=`echo "$file" | sed 's%^.*/%%'`
name=`echo "$file" | sed -e 's%^.*/%%'`
case "$name" in
- lib*.la)
+ *.la)
# Possibly a libtool archive, so verify it.
if egrep "^# Generated by $PROGRAM" $file >/dev/null 2>&1; then
. $dir/$name
NONE)
echo "$progname: you must specify a MODE" 1>&2
- echo "$help" 1>&2
+ echo "$generic_help" 1>&2
exit 1
;;
esac
projects / thirdparty / libtool.git / commitdiff
