Hi Dave,
# wget https://davehart.net/ntp/test/ntp-4.2.8p18-vcs.tar.xz
# tar xf *p18-vcs*xz
# cd *vcs
# ./bootstrap
After more testing, I don't believe it is a regression. If I install
1.16.5 in its own prefix, say /tmp/am165, the ntp bootstrap fails in the
same way:
Makefile.am:161: error: Libtool library used but 'LIBTOOL' is undefined
..
This is because, as Nick described in
https://lists.gnu.org/archive/html/automake/2024-06/msg00094.html
given a compile-time prefix of /tmp/whatever, there is nothing make
aclocal look into /usr/local/gnu (in your case, or whatever the real
<prefix>/share/aclocal is) to find the needed libtool.m4.
Thus, I was able to find libtool.m4 by explicitly telling aclocal about
the real system dir. Copying the invocation from what autoreconf was
doing (added -d to the autoreconf invocation in your bootstrap; BTW, you
might want to do that by default, because why not?):
aclocal --system-acdir=/usr/local/gnu/share/aclocal --verbose -I sntp/m4 -I sntp/libevent/m4 -I sntp/libopts/m4
did find libtool.m4 .
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)?
I can probably remember to either point automake at libtool or install libtool in the same prefix for future automake between-releases testing, but if this is (and perhaps has been) an issue, a couple of suggestions come to mind:
A) Perhaps the prerelease announcements should mention the issue somehow (e.g. suggesting also installing libtool to any test prefix, or pointing via 'autoreconf -d' or the environment variable).
B) Perhaps the libtool macros not found error message could hint at this cause alongside the stuff about ensuring LT_INIT is used.
Thanks again,
Dave Hart