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: 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: bug#71847: Self-inflicted problem, libtool and automake installed to different prefixes
Date: Tue, 2 Jul 2024 20:58:55 -0400

On 2024-07-02 13:34, Dave Hart wrote:
> Thanks for running this down, Karl.  I'm happy if you're happy, but I
> am left with one question:  Why is it installing prerelease automake
> in a different prefix for testing hasn't required also installing
> libtool to the same prefix (think back to your "baffled" comment)?

For autoreconf to work with libtool there just needs to be a definition
of LT_INIT available when it runs autoconf for the first time, in order
for the traces to indicate an expansion of LT_INIT.  There are a variety
of ways this might happen.

Since libtoolize copies its macro files into the project workspace, in a
typical configuration aclocal still will pick up definitions from the
workspace, even if it doesn't actually know how to find the installed
macro definitions.  Then autoreconf will run libtoolize, which copies
them in, and re-runs aclocal which should find the (possibly updated)
definitions.

So I'd only expect to encounter any issue if running autoreconf from
a "clean" workspace that has not previously run libtoolize.  Or if
libtool.m4 has been deleted prior to running autoreconf.  So unless
some care is taken to ensure the test environment really is the same
every time it's possible that the "working" results are just a fluke.

But none of this is meant to suggest that there isn't actually some real
change in aclocal behaviour which is causing the results you are seeing.

Cheers,
  Nick

Previous Next

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