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

Previous Next

Full log

Message #45 received at 71847 <at> debbugs.gnu.org (full text, mbox):

From: Nick Bowler <nbowler <at> draconx.ca>
To: Dave Hart <davehart <at> gmail.com>
Cc: 71847 <at> debbugs.gnu.org, Karl Berry <karl <at> freefriends.org>
Subject: Re: bug#71847: Self-inflicted problem, libtool and automake installed
 to different prefixes
Date: Wed, 3 Jul 2024 15:52:40 -0400

On 2024-07-03 09:37, Dave Hart wrote:
> On Wed, 3 Jul 2024 at 03:49, Dave Hart <davehart <at> gmail.com> wrote:
> > It occurs to me we might avoid issues along these lines by having
> > our bootstrap script invoke libtoolize before autoreconf.
[...]
> I tried this approach and it didn't help.  libtoolize seems to be
> doing the right thing, but I still see automake decide it't not
using libtool.

I think this is because you have multiple different sub-projects using
libtool, so for this to work libtoolize needs to be run multiple times
in different sub-directories.

All of this could probably be improved.  If aclocal provided a default
stub definition of LT_INIT then everything would probably "just work":
LT_INIT will appear in the traces, autoreconf will run libtoolize, and
then aclocal will pick up the proper definition instead of the dummy
default.  You could perhaps simulate such an effect by putting something
like this into acinclude.m4 (for each sub-project):

  m4_pattern_forbid([^LT_INIT$])
  m4_ifndef([LT_INIT], [AC_DEFUN([LT_INIT], [[$0]])])

since aclocal puts acinclude.m4 into aclocal.m4 at the very end,
this will do nothing if the libtool macros are properly picked up by
aclocal.  If they were not properly picked up, the dummy expansion
will match the forbidden pattern so autoconf can produce a reasonable
fatal error.

Cheers,
  Nick

Previous Next

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