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: Dave Hart <davehart <at> gmail.com>
To: Nick Bowler <nbowler <at> draconx.ca>
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: Thu, 4 Jul 2024 04:42:56 +0000

[Message part 1 (text/plain, inline)]

On Wed, 3 Jul 2024 at 19:52, Nick Bowler <nbowler <at> draconx.ca> wrote:

> 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.
>

I tried that approach, modifying the NTP bootstrap script to have:

cd sntp/libevent
libtoolize
cd ..
libtoolize
cd ..
libtoolize

immediately before the autoreconf invocation.  That does work around the
problem, and I can commit that change, though it seems like it's going to
slow every bootstrap for us (which we do frequently) to work around a
relatively rare issue.


> 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.
>

That sounds like a productive avenue.  That should work to prevent this
issue from arising with testing the NTP code against a prerelease Automake
installed in a prefix without libtool, and would probably avoid the
slowdown of three libtoolize invocations before autoreconf in our bootstrap
script.  But wouldn't it be better to make such a solution part of Automake
and have it gracefully handle this situation for everyone?

Thanks to both of you for your time spelunking this rabbit hole with me.

Cheers,
Dave Hart

[Message part 2 (text/html, inline)]

Previous Next

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