[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: libtool --ltdl vs. autoreconf
Re: libtool --ltdl vs. autoreconf
Thu, 25 May 2006 18:39:38 +0200
> * Eric Blake wrote on Tue, May 09, 2006 at 02:04:23PM CEST:
> > As promised here,
> > http://lists.gnu.org/archive/html/m4-patches/2006-05/msg00005.html, I
> > noticed that m4 bootstrap invokes libtoolize --ltdl prior to autoreconf,
> > which reinvokes libtoolize without --ltdl. This seems like a bit of a
> > waste of time, but when I tried removing the explicit libtoolize line, I
> > got a bootstrap failure that a required file, ltmain.sh, was not found. I
> > thought that using LT_CONFIG_LTDL_DIR in configure.ac would take care of
> > everything that --ltdl used to do on the command line, but I was obviously
> > mistaken.
Well, here's a patch to do what you intend. I'm not totally certain
that this is safe to apply. There are a few issues with this:
Having autoreconf infer the --ltdl argument is safer than having
libtoolize infer the --ltdl argument itself: this way, you can still
resort to not using autoreconf if that would be wrong. (And it's safe
in that for Libtool-1.5.x users nothing will change, until they
upgrade.) However, IMO libtoolize should infer the right directory to
put libltdl into, that's not autoreconf's job.
For example, with a pristine CVS checkout of M4, and deleting the
libtoolize invocation from `bootstrap', the aclocal call in the toplevel
will happen before libtoolize is called; since aclocal isn't called with
`--install' (well, that would work with CVS Automake aclocal only).
So, the Libtool macro files aren't in place yet, so the whole of them
ends up copied into aclocal.m4. This is then fixed after a second
Which opens up an interesting side question: should autoreconf-2.60 be
prepared for `aclocal-1.10 --install'?
Back to Libtool, the next issue is that, currently, the patch below will
cause libltdl to be copied twice: once from the toplevel dir, and once
from within the libltdl dir. This is ugly and error-prone. On the one
hand, we want `libtoolize --ltdl=.' to copy libltdl, on the other, we
don't want `libtoolize --ltdl' to copy libltdl if
`LT_CONFIG_LTDL_DIR([.])' is found; so I guess we should make libtoolize
change behavior between detected libltdl-directory `.' and passed
directory `.'. (All of this is in recursive-ltdl-mode.) I definitely
do not want to have to put more of this logic into autoreconf.
Then, currently inside a libltdl subdir, libtoolize wrongly suggests:
| libtoolize: Consider using `AC_CONFIG_AUX_DIR([./config])' in configure.ac.
| libtoolize: Consider using `AC_CONFIG_MACRO_DIR([./m4])' in configure.ac.
This is a libtoolize bug.
(First, these macros are already used, second, the arguments should not
start with `./', to cater for non-GNU make.)
I haven't done exhaustive testing with this yet. I'd appreciate results
how this fares with other packages using CVS Libtool.
* bin/autoreconf.in: Trace `LT_CONFIG_LTDL_DIR'; if it has been
seen, invoke libtoolize with `--ltdl' argument.
RCS file: /cvsroot/autoconf/autoconf/bin/autoreconf.in,v
retrieving revision 1.133
diff -u -r1.133 autoreconf.in
--- bin/autoreconf.in 18 May 2006 06:50:35 -0000 1.133
+++ bin/autoreconf.in 25 May 2006 15:53:00 -0000
@@ -442,6 +442,7 @@
+ my $uses_libltdl;
@@ -457,6 +458,7 @@
@@ -467,6 +469,7 @@
$uses_autoconf = 1 if /AC_INIT/;
$uses_gettext_via_traces = 1 if /AM_GNU_GETTEXT/;
$uses_libtool = 1 if /(AC_PROG_LIBTOOL|LT_INIT)/;
+ $uses_libltdl = 1 if /LT_CONFIG_LTDL_DIR/;
$uses_autoheader = 1 if /AC_CONFIG_HEADERS/;
$uses_automake = 1 if /AM_INIT_AUTOMAKE/;
push @subdir, split (' ', $1) if /AC_CONFIG_SUBDIRS:(.*)/ && $recursive;
@@ -521,6 +524,10 @@
+ if ($uses_libltdl)
+ $libtoolize .= " --ltdl";
$rerun_aclocal = 1;