On Mon, 8 Jul 2024 at 22:05, Karl Berry wrote:
> I've committed the changes below to help give more hints about the need
> to run libtoolize. I ended up adding a new section to the manual and
> referring to it from the alpha-NEWS and variable warning. It's in the
> below patch as the new
> @nod
I've committed the changes below to help give more hints about the need
to run libtoolize. I ended up adding a new section to the manual and
referring to it from the alpha-NEWS and variable warning. It's in the
below patch as the new
@node Libtool library used but LIBTOOL is undefined
After maki
While I agree I can avoid this problem with the acinclude.m4
approach, I'm hesitant to do so because it's a corner case we don't
hit that often, I'd rather put my effort into a general fix for
everyone.
I understand. OTOH, I can say that putting Nick's m4 magic into your
acinclude.
On Thu, 4 Jul 2024 at 22:27, Karl Berry wrote:
> slow every bootstrap for us (which we do frequently) to work around a
> relatively rare issue.
>
> Nick's solution of using acinclude.m4 seems ideal. But just in case: I
> think you could also avoid the extra libtoolize calls by doing them
slow every bootstrap for us (which we do frequently) to work around a
relatively rare issue.
Nick's solution of using acinclude.m4 seems ideal. But just in case: I
think you could also avoid the extra libtoolize calls by doing them only
if the automake --version is x.y.9*, i.e., a test rel
On Wed, 3 Jul 2024 at 19:52, Nick Bowler wrote:
> On 2024-07-03 09:37, Dave Hart wrote:
> > On Wed, 3 Jul 2024 at 03:49, Dave Hart wrote:
> > > It occurs to me we might avoid issues along these lines by having
> > > our bootstrap script invoke libtoolize before autoreconf.
> [...]
> > I tried th
libtoolize: linking file `sntp/m4/libtool.m4'
Indeed, that seems like it should work, because the aclocal invocation
from autoreconf is looking into sntp/m4 (and /m4 too) and
finds other files there:
..
autoreconf: running: aclocal --verbose --verbose -I sntp/m4 -I sntp/libevent/m4
-I sntp/l
> 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.
I've failed to find any regression. As I said, if I install 1.16.5 into
a test --prefix and run ntp's bootstrap with that prefix, it cannot
On 2024-07-03 09:37, Dave Hart wrote:
> On Wed, 3 Jul 2024 at 03:49, Dave Hart 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
> doin
On Wed, 3 Jul 2024 at 03:49, Dave Hart wrote:
>
> It occurs to me we might avoid issues along these lines by having our
> bootstrap script invoke libtoolize before autoreconf. Does that sound wise
> to the two of you?
>
I tried this approach and it didn't help. libtoolize seems to be doing the
On Wed, 3 Jul 2024 at 00:58, Nick Bowler wrote:
> 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 happe
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 "
Hi Dave,
Why is it installing prerelease automake in a different prefix for
testing hasn't required also installing libtool to the same prefix
In general, I think it does. And always has. This is not new behavior,
as far as I can see.
(think back to your "baffled" comment)?
Indeed :
On Tue, 2 Jul 2024 at 17:15, Karl Berry wrote:
> 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 /t
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:16
Repro steps
Thanks. Evidently something must have changed in automake's libtool
support, but looking at the ChangeLog, I don't see it. I will look into
it ... --thanks, karl.
On Sun, 30 Jun 2024 at 20:31, Karl Berry wrote:
> Hi Dave,
>
> installed and installing the prerelease version to a prefix earlier on
> my
> $PATH, not realizing I also needed to install libtool to the same
> prefix
>
> Well, I'm glad that it's apparently not a "real" problem, but I'm rat
Hi Dave,
installed and installing the prerelease version to a prefix earlier on my
$PATH, not realizing I also needed to install libtool to the same prefix
Well, I'm glad that it's apparently not a "real" problem, but I'm rather
baffled. When I test an automake pretest, I don't do anythi
Nick Bowler helped educate me on aclocal and libtool interaction on the
Automake mailing list. The reason I was hitting this problem was aclocal
was not finding libtool installed to the same prefix as automake. To test
the prerelease automake I was leaving the base version of automake
installed a
19 matches
Mail list logo
