GNU bug report logs - #71847
Automake 1.16.90 regression mistakenly "not using Libtool"

Previous Next

Full log

View this message in rfc822 format

From: Karl Berry <karl <at> freefriends.org>
To: davehart <at> gmail.com
Cc: nbowler <at> draconx.ca, 71847 <at> debbugs.gnu.org
Subject: bug#71847: Self-inflicted problem, libtool and automake installed to different prefixes
Date: Thu, 4 Jul 2024 16:27:36 -0600

    slow every bootstrap for us (which we do frequently) to work around a
    relatively rare issue.

Nick's solution of using acinclude.m4 seems ideal. But just in case: I
think you could also avoid the extra libtoolize calls by doing them only
if the automake --version is x.y.9*, i.e., a test release. Or, more
directly, check for $automakeprefix>/share/aclocal*/libtool.m4 and only
do the libtoolize if not already there.  I mean, where
  automake_prefix=$(dirname $(which automake))/.. 
Or something like that. You get the idea, I'm sure :).

    But wouldn't it be better to make such a solution part of Automake
    and have it gracefully handle this situation for everyone?

Sure, clearly a graceful solution for everyone would be ideal. But in
terms of the pending 1.17 release, I don't want to do something as
potentially destabilizing as defining a stub LT_INIT in aclocal. That
seems like it has great potential for confusion and problems.

Also, looking at Automake/Variable.pm, there are a bunch of
various/functions handled in the same way, e.g., CC vs. AC_PROG_CC
just like LIBTOOL vs. LT_INIT. Although I think LT_INIT is the only one
not defined by Automake or Autoconf.

At any rate, It would also be nice to see an actual patch, since my
knowledge of aclocal/automake<->libtool interaction is limited, at best,
so I'm not sure offhand where or how to make such a change.

Meanwhile, I'll at least tweak the (test relese) NEWS and error message
as you suggested. --thanks, karl.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.