bug#71847: Self-inflicted problem, libtool and automake installed to different prefixes

On Wed, 3 Jul 2024 at 19:52, Nick Bowler <[email protected]> wrote:

> On 2024-07-03 09:37, Dave Hart wrote:
> > On Wed, 3 Jul 2024 at 03:49, Dave Hart <[email protected]> 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