In the near future:
********************
-* check whether the version of libtool.m4 is compatible
-with ltconfig/ltmain.sh
+* Check whether the version of libtool.m4 is compatible with
+ltconfig/ltmain.sh. Meanwhile, the recommended approach for
+developers using automake is to insert libtool.m4 in acinclude.m4.
* We could have an option to hardcode paths into libraries, as well as
binaries: `... -Wl,-soname -Wl,/tmp/libtest.so.0 ...'. This is not
create shared libraries, whereas the .a would be used for creating
static libraries and programs.
+* We should include tests with convenience libraries and reloadable
+objects in the testsuite.
+
* Try to find a work-around for -[all-]static and libltdl on platforms
-that will fail to find dlopening functions in this case, such as AIX
-4.3.2.0. Maybe creating an alternate libltdl that provides only for
-dlpreopening, or creating an additional static library to provide
-dummy implementations of the functions that can't be linked
-statically. This could hardly be made completely transparent, though.
+that will fail to find dlopening functions in this case. Maybe
+creating an alternate libltdl that provides only for dlpreopening, or
+creating an additional static library to provide dummy implementations
+of the functions that can't be linked statically. This could hardly
+be made completely transparent, though.
* Need to finalize the documentation, and give a specification of
-`.la' files so that people can depend on their format. This also
-needs to be done so that DLD uses a public interface to libtool
-archives. This would be a good thing to put before the maintainance
-notes.
+`.la' files so that people can depend on their format. This would be
+a good thing to put before the maintainance notes.
* Filenames containing shell meta-characters are not properly handled
by libtool. Compiling a file named "a;b.c", for example, fails.
+* We could introduce a mechanism to allow for soname rewriting, to
+ease multi-libc support. Installers could specify a prefix, suffix or
+sed command to modify the soname, and libtool would create the
+corresponding link. This would allow for rebuilding a library with
+the same version number, but depending on different versions of libc,
+for example. In the future, we might even have an option to encode
+the sonames of all dependencies of a library into its soname.
+
Things to think about:
**********************
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 from
-other directories, because it supports linking with libraries from other
-directories.
+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 old @code{ar} and
libhello_la_LDFLAGS = -version-info 3:12:1
@end example
-The @samp{-rpath} option is passed automatically by Automake, so you
+The @samp{-rpath} option is passed automatically by Automake (except for
+libraries listed as @code{noinst_LTLIBRARIES}), so you
should not specify it.
@xref{A Shared Library, Building a Shared Library, The Automake Manual,
will automatically add @code{AM_PROG_LIBTOOL} support to your
@code{configure} script.
+Nevertheless, it is advisable to include a copy of @file{libtool.m4} in
+@file{acinclude.m4}, so that, even if @file{aclocal.m4} and
+@file{configure} are rebuilt for any reason, the appropriate libtool
+macros will be used. The alternative is to hope the user will have a
+compatible version of @file{libtool.m4} installed and accessible for
+@code{aclocal}. This may lead to wierd errors when versions don't
+match.
+
@node Distributing
@section Including libtool in your package
@file{configure.in} will configure libltdl, using
@samp{AC_CONFIG_SUBDIRS}, and that your @file{Makefile}s will start
sub-makes within libltdl's directory, using automake's @var{SUBDIRS},
-for example. Both macros define the shell variable @var{LIBLTDL} to
-the link flag that you should use to link with libltdl. It is up to you
-to use @samp{AC_SUBST} to ensure that this variable will be available in
-@file{Makefile}s.
-
-If you're using the convenience libltdl, it will be the pathname for the
-convenience version of libltdl, starting with @samp{$@{top_builddir@}/}.
-Otherwise, if an installed version of libltdl is found, @var{LIBLTDL}
-will be set to @samp{-lltdl}. If an installable version of libltdl must
-be built, its pathname, starting with @samp{$@{top_builddir@}/}, will be
-stored in @var{LIBLTDL}. So, when you want to link a program with
-libltdl, just link it with @samp{$(LIBLTDL)}.
+for example. Both macros define the shell variables @var{LIBLTDL}, to
+the link flag that you should use to link with libltdl, and
+@var{INCLTDL}, to the preprocessor flag that you should use to compile
+with programs that include @file{ltdl.h}. It is up to you to use
+@samp{AC_SUBST} to ensure that this variable will be available in
+@file{Makefile}s, or add them to variables that are @samp{AC_SUBST}ed by
+default, such as @var{LIBS} and @var{CPPFLAGS}.
+
+If you're using the convenience libltdl, @var{LIBLTDL} will be the
+pathname for the convenience version of libltdland @var{INCLTDL} will be
+@samp{-I} followed by the directory that contains libltdl, both starting
+with @samp{$@{top_builddir@}/}.
+
+If you request an installed version of libltdl and one is
+found@footnote{Even if libltdl is installed,
+@samp{AC_LIBLTDL_INSTALLABLE} may fail to detect it, if libltdl depends
+on symbols provided by libraries other than the C library. In this
+case, it will needlessly build and install libltdl.}, @var{LIBLTDL} will
+be set to @samp{-lltdl} and @var{INCLTDL} will be empty (which is just a
+blind assumption that @file{ltdl.h} is somewhere in the include path if
+libltdl is in the library path). If an installable version of libltdl
+must be built, its pathname, starting with @samp{$@{top_builddir@}/},
+will be stored in @var{LIBLTDL}, and @var{INCLTDL} will be set just like
+in the case of convenience library.
+
+So, when you want to link a program with libltdl, be it a convenience,
+installed or installable library, just compile with @samp{$(INCLTDL)}
+and link it with @samp{$(LIBLTDL)}, using libtool.
You should probably also add @samp{AC_LIBTOOL_DLOPEN} to your
@file{configure.in} @emph{before} @samp{AM_PROG_LIBTOOL}, otherwise
linking programs with libltdl. This will not work on all plaforms,
because the dlopening functions may not be available for static linking.
-The following example shows you how to embed the convenience libltdl
-in your package. In order to use the installable variant just replace
-AC_LIBLTDL_CONVENIENCE with AC_LIBLTDL_INSTALLABLE. We assume that
-libltdl was embedded using @samp{libtoolize --ltdl}.
+The following example shows you how to embed the convenience libltdl in
+your package. In order to use the installable variant just replace
+@samp{AC_LIBLTDL_CONVENIENCE} with @samp{AC_LIBLTDL_INSTALLABLE}. We
+assume that libltdl was embedded using @samp{libtoolize --ltdl}.
configure.in:
@example
AC_LIBLTDL_CONVENIENCE
dnl Substitute LIBLTDL in the Makefiles
AC_SUBST(LIBLTDL)
+dnl Add INCLTDL to the include path
+CPPFLAGS="$CPPFLAGS $INCLTDL"
dnl Configure libltdl
AC_CONFIG_SUBDIRS(libltdl)
...
projects / thirdparty / libtool.git / commitdiff
