From unknown Fri Aug 15 15:33:28 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#71847 <71847@debbugs.gnu.org> To: bug#71847 <71847@debbugs.gnu.org> Subject: Status: Automake 1.16.90 regression mistakenly "not using Libtool" Reply-To: bug#71847 <71847@debbugs.gnu.org> Date: Fri, 15 Aug 2025 22:33:28 +0000 retitle 71847 Automake 1.16.90 regression mistakenly "not using Libtool" reassign 71847 automake submitter 71847 Dave Hart severity 71847 normal tag 71847 notabug thanks From debbugs-submit-bounces@debbugs.gnu.org Sat Jun 29 18:50:17 2024 Received: (at submit) by debbugs.gnu.org; 29 Jun 2024 22:50:17 +0000 Received: from localhost ([127.0.0.1]:54051 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sNgtc-0004BU-Gt for submit@debbugs.gnu.org; Sat, 29 Jun 2024 18:50:17 -0400 Received: from lists.gnu.org ([209.51.188.17]:56570) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sNgcF-0003ef-LC for submit@debbugs.gnu.org; Sat, 29 Jun 2024 18:32:21 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sNbiY-0003gd-OO for bug-automake@gnu.org; Sat, 29 Jun 2024 13:18:30 -0400 Received: from mail-yb1-xb33.google.com ([2607:f8b0:4864:20::b33]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1sNbiW-0004Tq-6h for bug-automake@gnu.org; Sat, 29 Jun 2024 13:18:30 -0400 Received: by mail-yb1-xb33.google.com with SMTP id 3f1490d57ef6-e0361c767ddso1321397276.1 for ; Sat, 29 Jun 2024 10:18:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1719681507; x=1720286307; darn=gnu.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=rtLzqk/heEBhQofRu/q4s6DlWxYuo0XoxP7AiGQsgrg=; b=KsGqP+/QxUva0qRDsoBZEosY4bREbHOsdJ+99Wlrvn5KsG4obw73YefVYmBaSk8cCd nnaxkl+2GcBnK1EoC5QruSE5nrz+czBcTgn4SCvCvQXk6+yGXRcJfxnkJO0Hw0oWkcXI mWMdny9ZRM7MoyjdsYwVnxcC6pUzk9RmtGCK7y7/02BF3lQ78a8s2PqO9GgzWROrra3/ /m8pdZ2rvrnL0GUn2mKYr4EQSH/AjO9bF3dfFwyGD3LUwUrwxgRY5MOFN9+2TuNHMTaA wL1EZVLVa6PIH0N1ystPZVSas350HP0FMHlfbsaR8VreTtO4UoUKB04hLiyhw6jvjU7v HofA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1719681507; x=1720286307; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=rtLzqk/heEBhQofRu/q4s6DlWxYuo0XoxP7AiGQsgrg=; b=nHC6dd4aEnchicTozRSncZwlF9zS5UG+ddxkkUPI1KyEIosnT9WmtexUhv89DXFxoE r6q6HjT/AKWjXo+hHzXUxjDh9G1Y3BOFVxqrGcJ8uzQ9X0av7g/tpYveuCKXE0QOzUqT NYbEEkwDgh2mBZwg7maGSFAbRIq7fwGJfa9MoJUGh7JgWMOlT1d9j4MOnPtoxhM931Zw 20HZ0T9wVA+55MGMEgJYypTM0Fc8e4eAaslkZuE+6ikPS1FMtJk8XNjIuMha0vuvNEac o3sPmw8AbSkDHbq9CpUOnmfw3OWvilwpKL3dLA/+GaI7RKFOxUg914A98Qv4ZLRD/zaP gXTQ== X-Gm-Message-State: AOJu0YzYHhuA4LpzSG+9Uht/MUCWLWHJyMmEZb1Wk5BfbmZMMjgEry4H Amd9IvnelEDMlkfXGM3+q9qW4A2zxI/DGydCkPo/cdu85ZxYEHBtPSI4FB4iavzHMqUyFRBL2oV ULjQ+V39HhDgEVJ0tjFCP033m7RH+Bmg9 X-Google-Smtp-Source: AGHT+IGAcX2+/cFEjO8I8FVIVyjIjVFdgvRdS80e0AGyX9+jpUo1/aXiJUxdZF22EwJGaBJ44I3G3D9YfTYuQ3/HjNA= X-Received: by 2002:a25:b47:0:b0:e03:3d38:fb26 with SMTP id 3f1490d57ef6-e036eb9847bmr1546843276.28.1719681506535; Sat, 29 Jun 2024 10:18:26 -0700 (PDT) MIME-Version: 1.0 From: Dave Hart Date: Sat, 29 Jun 2024 17:18:15 +0000 Message-ID: Subject: Automake 1.16.90 regression mistakenly "not using Libtool" To: bug-automake@gnu.org Content-Type: multipart/mixed; boundary="000000000000533766061c0a8d88" Received-SPF: pass client-ip=2607:f8b0:4864:20::b33; envelope-from=davehart@gmail.com; helo=mail-yb1-xb33.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, WEIRD_PORT=0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.3 (-) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) --000000000000533766061c0a8d88 Content-Type: multipart/alternative; boundary="000000000000533764061c0a8d86" --000000000000533764061c0a8d86 Content-Type: text/plain; charset="UTF-8" I'm seeing a problem building ntpd from a Bitkeeper repo that doesn't occur with a make dist tarball when using Automake 2.71 and Automake 1.16.90 or 1.16.92 that reliably does not occur with Automake 1.16.5. To enable easy reproduction, I've made a tarball of the source from a checkout of NTP 4.2.8p18 available at: https://davehart.net/ntp/test/ntp-4.2.8p18-vcs.tar.xz Most of my testing was on FreeBSD 12.1 with stock m4, perl 5.32.1 and Automake 2.71 using Automake 1.16.5, 1.16.90, and 1.16.92 from tarball source: FreeBSD hart.chi1.ntfo.org 12.1-RELEASE_SI FreeBSD 12.1-RELEASE_SI TEMPLATE amd64 I've reproduced the failure on Ubuntu 22.04 , gm4 1.4.18, perl 5.34.0, and both stock Autoconf 2.71 and 2.72 from tarball source, and the success with distro Automake 1.16.5: Linux dlh-22-04 6.5.0-1022-azure #23~22.04.1-Ubuntu SMP Thu May 9 17:59:24 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux While the FreeBSD system is building on NFS with 1s mtime resolution, the Ubuntu is building on local ext4 with subsecond mtimes. The error occurs during `autoreconf -v -i` like so # tar xf ntp-4.2.8p18-vcs.tar.xz # cd ntp-*-vcs # ./bootstrap 2>&1 | tee bootstrap.log I'm attaching logs showing the behavior on Ubuntu with ac 2.72 and am 1.16.5 vs 1.16.92. The differences up to the failure are below. The bootstrap script is modified slightly compared to the one in ntp-4.2.8p18.tar.gz and our bk repos to sort the filenames touched early in the script to minimize unhelpful diff clutter. --- bootstrap-am-1.16.5.log 2024-06-29 16:54:55.290591021 +0000 +++ bootstrap-am-1.16.92.log 2024-06-29 17:00:56.366844439 +0000 @@ -19,162 +19,33 @@ autoreconf: running: aclocal -I m4 autoreconf: configure.ac: tracing autoreconf: configure.ac: creating directory build-aux -autoreconf: running: libtoolize --copy -libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, 'build-aux'. -libtoolize: copying file 'build-aux/ltmain.sh' -libtoolize: putting macros in AC_CONFIG_MACRO_DIRS, 'm4'. -libtoolize: copying file 'm4/libtool.m4' -libtoolize: copying file 'm4/ltoptions.m4' -libtoolize: copying file 'm4/ltsugar.m4' -libtoolize: copying file 'm4/ltversion.m4' -libtoolize: copying file 'm4/lt~obsolete.m4' +autoreconf: configure.ac: not using Libtool autoreconf: configure.ac: not using Intltool autoreconf: configure.ac: not using Gtkdoc -autoreconf: running: aclocal -I m4 -autoreconf: running: /usr/local/bin/autoconf -configure.ac:46: warning: The macro 'AC_PROG_GCC_TRADITIONAL' is obsolete. -configure.ac:46: You should run autoupdate. -../lib/autoconf/c.m4:1676: AC_PROG_GCC_TRADITIONAL is expanded from... -configure.ac:46: the top level -configure.ac:357: warning: The macro 'AC_HEADER_TIME' is obsolete. +autoreconf: running: /usr/bin/autoconf +configure.ac:357: warning: The macro `AC_HEADER_TIME' is obsolete. configure.ac:357: You should run autoupdate. -../lib/autoconf/headers.m4:702: AC_HEADER_TIME is expanded from... +./lib/autoconf/headers.m4:743: AC_HEADER_TIME is expanded from... configure.ac:357: the top level -configure.ac:805: warning: The macro 'AC_TRY_LINK' is obsolete. +configure.ac:805: warning: The macro `AC_TRY_LINK' is obsolete. configure.ac:805: You should run autoupdate. -../lib/autoconf/general.m4:2918: AC_TRY_LINK is expanded from... +./lib/autoconf/general.m4:2920: AC_TRY_LINK is expanded from... m4/acx_pthread.m4:86: ACX_PTHREAD is expanded from... configure.ac:805: the top level configure.ac:1012: warning: AC_OUTPUT should be used without arguments. configure.ac:1012: You should run autoupdate. -autoreconf: running: /usr/local/bin/autoheader +autoreconf: running: /usr/bin/autoheader autoreconf: running: automake --add-missing --copy --no-force configure.ac:24: installing 'build-aux/compile' configure.ac:26: installing 'build-aux/config.guess' configure.ac:26: installing 'build-aux/config.sub' configure.ac:14: installing 'build-aux/install-sh' configure.ac:14: installing 'build-aux/missing' +Makefile.am:161: error: Libtool library used but 'LIBTOOL' is undefined +Makefile.am:161: The usual way to define 'LIBTOOL' is to add 'LT_INIT' +Makefile.am:161: to 'configure.ac' and run 'aclocal' and 'autoconf' again. +Makefile.am:161: If 'LT_INIT' is in 'configure.ac', make sure +Makefile.am:161: its definition is in aclocal's search path. Makefile.am: installing 'build-aux/depcomp' parallel-tests: installing 'build-aux/test-driver' -autoreconf: Leaving directory 'libevent' -autoreconf: running: libtoolize --copy [...] -ls: invalid tab size: './aclocal.m4' +autoreconf: error: automake failed with exit status: 1 -- Cheers, Dave Hart --000000000000533764061c0a8d86 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'm seeing a problem building ntpd fro= m a Bitkeeper repo that doesn't occur with a make dist tarball when usi= ng Automake 2.71 and Automake 1.16.90 or 1.16.92 that reliably does not occ= ur=C2=A0with Automake 1.16.5.=C2=A0 To enable easy reproduction, I've m= ade a tarball of the source from a checkout of NTP 4.2.8p18 available at:

https://davehart.net/ntp/test/ntp-4.2.= 8p18-vcs.tar.xz

Most= of my testing was on FreeBSD 12.1 with stock m4, perl 5.32.1 and=C2=A0 Aut= omake 2.71 using Automake 1.16.5, 1.16.90, and 1.16.92 from tarball source:=

FreeBSD hart.chi1.ntfo.org 12.1-RELEASE_SI FreeBSD 12.1-RELEASE_SI TEMP= LATE =C2=A0amd64

I've reproduced the failure on Ubuntu 22.04 , gm4 1.4.18, perl 5.= 34.0, and both stock Autoconf 2.71 and 2.72 from tarball source, and the su= ccess with distro Automake 1.16.5:

Linux dlh-22-04 6.5.0-1022-azure #23~22.04.1-Ubuntu SMP Thu May = =C2=A09 17:59:24 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux
While the FreeBSD system is buildi= ng on NFS with 1s mtime resolution, the Ubuntu is building on local ext4 wi= th subsecond mtimes.

The er= ror occurs during `autoreconf -v -i` like so

# tar xf ntp-4.2.8p18-vcs.tar.xz
# cd = ntp-*-vcs
# ./bootstrap 2>&1 | tee bootstrap.log

I'm attaching logs= showing the behavior on Ubuntu with ac 2.72 and am 1.16.5 vs 1.16.92.=C2= =A0 The differences up to the failure are below.

The bootstrap script is modifi= ed slightly compared to the one in ntp-4.2.8p18.tar.gz and our bk repos to = sort the filenames touched early in the script to minimize unhelpful diff c= lutter.


=
--- bootstrap-am-1.16.5.log 2024-06-29 16:54:55.290591021= +0000
+++ bootstrap= -am-1.16.92.log =C2=A0 =C2=A02024-06-29 17:00:56.366844439 +0000
@@ -19,162 +19,33 @@
=C2=A0autoreconf: running: aclocal -I= m4
=C2=A0autoreconf: configure.a= c: tracing
=C2=A0autoreconf: = configure.ac: creating directory build-aux
-autoreconf: running: libtoolize --copy
-libtoolize: putting auxiliary fi= les in AC_CONFIG_AUX_DIR, 'build-aux'.
-libtoolize: copying file 'build-aux/ltmain= .sh'
-libtooliz= e: putting macros in AC_CONFIG_MACRO_DIRS, 'm4'.
<= span style=3D"color:rgb(206,145,120)">-libtoolize: copying file 'm4/lib= tool.m4'
-libto= olize: copying file 'm4/ltoptions.m4'
-libtoolize: copying file 'm4/ltsugar.m4= 9;
-libtoolize: cop= ying file 'm4/ltversion.m4'
-libtoolize: copying file 'm4/lt~obsolete.m4'
+autoreconf: configure.ac: not using Libtool
= =C2=A0autoreconf: configure.ac: not usi= ng Intltool
=C2=A0autoreconf: con= figure.ac: not using Gtkdoc
-autoreconf: running: aclocal -I m4
-autoreconf: running: /usr/local/bin/autoconf=
-configure.ac:46: warning: The macro 'AC_PROG_GCC_TRADITI= ONAL' is obsolete.
-configure.ac:46: You should run= autoupdate.
-../li= b/autoconf/c.m4:1676: AC_PROG_GCC_TRADITIONAL is expanded from...
-configure.ac:46: the top level
-configure.ac:3= 57: warning: The macro 'AC_HEADER_TIME' is obsolete.
+autoreconf: running: /usr/bi= n/autoconf
+configure.ac:357: warning: The macro `AC_H= EADER_TIME' is obsolete.
=C2=A0configure.ac:357: You should run autoupdate.
-../lib/autoconf/headers.m4:702: AC_HEA= DER_TIME is expanded from...
+./lib/autoconf/headers.m4:743: AC_HEADER_TIME is expanded from..= .
=C2=A0configure.ac:3= 57: the top level
-configure.ac:805: warning: The macro &= #39;AC_TRY_LINK' is obsolete.
+configure.ac:805: w= arning: The macro `AC_TRY_LINK' is obsolete.
=C2=A0configure.ac:805: You should run autou= pdate.
-../lib/autoconf/ge= neral.m4:2918: AC_TRY_LINK is expanded from...
+./lib/autoconf/general.m4:2920: AC_TRY_LINK is= expanded from...
=C2=A0m4/acx_pthread.m4:86: ACX_PTHREAD = is expanded from...
=C2=A0con= figure.ac:805: the top level
=C2=A0configure.ac:1012: warning: AC_OUTPUT should be used without= arguments.
=C2=A0configure.= ac:1012: You should run autoupdate.
-autoreconf: running: /usr/local/bin/autoheader
<= div>+autoreconf: running: /usr/bin/a= utoheader
=C2=A0autoreconf: running: automake --add-missin= g --copy --no-force
=C2=A0conf= igure.ac:24: installing 'build-aux/compile'
=C2=A0configure.ac:26: installing 'build-= aux/config.guess'
=C2=A0co= nfigure.ac:26: installing 'build-aux/config.sub'
=C2= =A0configure.ac:14: installing '= build-aux/install-sh'
=C2=A0configure.ac:14: installing 'build-aux/missing'
+Makefile.am:161: error: Libtool librar= y used but 'LIBTOOL' is undefined
+Makefile.am:161: =C2=A0 The usual way to define = 9;LIBTOOL' is to add 'LT_INIT'
+Makefile.am:161: =C2=A0 to 'configure.ac' and run 'aclocal' and 'auto= conf' again.
+M= akefile.am:161: =C2=A0 If 'LT_INIT' is in 'configure.ac', make sure
+Makefile.am:161: =C2=A0 its definition is in a= clocal's search path.
=C2=A0Makefile.am: installing &#= 39;build-aux/depcomp'
=C2=A0parallel-tests: installing 'b= uild-aux/test-driver'
= -autoreconf: Leaving directory 'libevent'
-autoreconf: running: libtoolize --copy
[...]
-ls:= invalid tab size: './aclocal.m4'
+autoreconf: error: automake failed with exit status= : 1
--
Cheers,
Da= ve Hart
--000000000000533764061c0a8d86-- --000000000000533766061c0a8d88 Content-Type: application/octet-stream; name="bootstrap-am-1.16.5.log" Content-Disposition: attachment; filename="bootstrap-am-1.16.5.log" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_ly0dvc750 VG91Y2hpbmcgPCBzbnRwL3Rlc3RzL2NyeXB0by5jIHNudHAvdGVzdHMva2V5RmlsZS5jIHNudHAv dGVzdHMva29kRGF0YWJhc2UuYyBzbnRwL3Rlc3RzL2tvZEZpbGUuYyBzbnRwL3Rlc3RzL25hbWVy ZXNvbHV0aW9uLmMgc250cC90ZXN0cy9uZXR3b3JraW5nLmMgc250cC90ZXN0cy9wYWNrZXRIYW5k bGluZy5jIHNudHAvdGVzdHMvcGFja2V0UHJvY2Vzc2luZy5jIHNudHAvdGVzdHMvdC1sb2cuYyBz bnRwL3Rlc3RzL3V0aWxpdGllcy5jIHRlc3RzL2J1Zy0yODAzL2J1Zy0yODAzLmMgdGVzdHMvbGli bnRwL2FfbWQ1ZW5jcnlwdC5jIHRlc3RzL2xpYm50cC9hdG9pbnQuYyB0ZXN0cy9saWJudHAvYXRv dWludC5jIHRlc3RzL2xpYm50cC9hdXRoa2V5cy5jIHRlc3RzL2xpYm50cC9idWZ0dnRvdHMuYyB0 ZXN0cy9saWJudHAvY2FsZW5kYXIuYyB0ZXN0cy9saWJudHAvY2FsanVsaWFuLmMgdGVzdHMvbGli bnRwL2NhbHRvbnRwLmMgdGVzdHMvbGlibnRwL2NhbHllYXJzdGFydC5jIHRlc3RzL2xpYm50cC9j bG9ja3RpbWUuYyB0ZXN0cy9saWJudHAvZGVjb2RlbmV0bnVtLmMgdGVzdHMvbGlibnRwL2RpZ2Vz dHMuYyB0ZXN0cy9saWJudHAvaGV4dG9pbnQuYyB0ZXN0cy9saWJudHAvaGV4dG9sZnAuYyB0ZXN0 cy9saWJudHAvaHVtYW5kYXRlLmMgdGVzdHMvbGlibnRwL2xmcGZ1bmMuYyB0ZXN0cy9saWJudHAv bGZwdG9zdHIuYyB0ZXN0cy9saWJudHAvbW9kZXRvYS5jIHRlc3RzL2xpYm50cC9tc3lzbG9nLmMg dGVzdHMvbGlibnRwL25ldG9mLmMgdGVzdHMvbGlibnRwL251bXRvYS5jIHRlc3RzL2xpYm50cC9v Y3R0b2ludC5jIHRlc3RzL2xpYm50cC9wcmV0dHlkYXRlLmMgdGVzdHMvbGlibnRwL3JlYWxwYXRo LmMgdGVzdHMvbGlibnRwL3JlY3ZidWZmLmMgdGVzdHMvbGlibnRwL3JlZmlkc21lYXIuYyB0ZXN0 cy9saWJudHAvcmVmbnVtdG9hLmMgdGVzdHMvbGlibnRwL3NicHJpbnRmLmMgdGVzdHMvbGlibnRw L3NmcHRvc3RyLmMgdGVzdHMvbGlibnRwL3NvY2t0b2EuYyB0ZXN0cy9saWJudHAvc3NsX2luaXQu YyB0ZXN0cy9saWJudHAvc3RhdGVzdHIuYyB0ZXN0cy9saWJudHAvc3RydG9sZnAuYyB0ZXN0cy9s aWJudHAvdGltZXNwZWNvcHMuYyB0ZXN0cy9saWJudHAvdGltZXZhbG9wcy5jIHRlc3RzL2xpYm50 cC90c2FmZW1lbWNtcC5jIHRlc3RzL2xpYm50cC90c3RvdHYuYyB0ZXN0cy9saWJudHAvdHZ0b3Rz LmMgdGVzdHMvbGlibnRwL3VnbHlkYXRlLmMgdGVzdHMvbGlibnRwL3ZpNjRvcHMuYyB0ZXN0cy9s aWJudHAveW1kMnlkLmMgdGVzdHMvbnRwZC9sZWFwc2VjLmMgdGVzdHMvbnRwZC9udHBfcHJpb19x LmMgdGVzdHMvbnRwZC9udHBfcmVzdHJpY3QuYyB0ZXN0cy9udHBkL250cF91dGlsLmMgdGVzdHMv bnRwZC9yY19jbWRsZW5ndGguYyB0ZXN0cy9udHBkL3QtbnRwX3NjYW5uZXIuYyB0ZXN0cy9udHBk L3QtbnRwX3NpZ25kLmMgdGVzdHMvbnRwcS90LW50cHEuYyB0ZXN0cy9zYW5kYm94L2J1Zy0yODAz LmMgdGVzdHMvc2FuZGJveC9tb2RldG9hLmMgdGVzdHMvc2FuZGJveC91Z2x5ZGF0ZS5jIHRlc3Rz L3NhbmRib3gvdXQtMjgwMy5jIHRlc3RzL3NlYy0yODUzL3NlYy0yODUzLmM+ClRvdWNoaW5nIDwg c250cC90ZXN0cy9ydW4tY3J5cHRvLmMgc250cC90ZXN0cy9ydW4ta2V5RmlsZS5jIHNudHAvdGVz dHMvcnVuLWtvZERhdGFiYXNlLmMgc250cC90ZXN0cy9ydW4ta29kRmlsZS5jIHNudHAvdGVzdHMv cnVuLW5hbWVyZXNvbHV0aW9uLmMgc250cC90ZXN0cy9ydW4tbmV0d29ya2luZy5jIHNudHAvdGVz dHMvcnVuLXBhY2tldEhhbmRsaW5nLmMgc250cC90ZXN0cy9ydW4tcGFja2V0UHJvY2Vzc2luZy5j IHNudHAvdGVzdHMvcnVuLXQtbG9nLmMgc250cC90ZXN0cy9ydW4tdXRpbGl0aWVzLmMgdGVzdHMv YnVnLTI4MDMvcnVuLWJ1Zy0yODAzLmMgdGVzdHMvbGlibnRwL3J1bi1hX21kNWVuY3J5cHQuYyB0 ZXN0cy9saWJudHAvcnVuLWF0b2ludC5jIHRlc3RzL2xpYm50cC9ydW4tYXRvdWludC5jIHRlc3Rz L2xpYm50cC9ydW4tYXV0aGtleXMuYyB0ZXN0cy9saWJudHAvcnVuLWJ1ZnR2dG90cy5jIHRlc3Rz L2xpYm50cC9ydW4tY2FsZW5kYXIuYyB0ZXN0cy9saWJudHAvcnVuLWNhbGp1bGlhbi5jIHRlc3Rz L2xpYm50cC9ydW4tY2FsdG9udHAuYyB0ZXN0cy9saWJudHAvcnVuLWNhbHllYXJzdGFydC5jIHRl c3RzL2xpYm50cC9ydW4tY2xvY2t0aW1lLmMgdGVzdHMvbGlibnRwL3J1bi1kZWNvZGVuZXRudW0u YyB0ZXN0cy9saWJudHAvcnVuLWRpZ2VzdHMuYyB0ZXN0cy9saWJudHAvcnVuLWhleHRvaW50LmMg dGVzdHMvbGlibnRwL3J1bi1oZXh0b2xmcC5jIHRlc3RzL2xpYm50cC9ydW4taHVtYW5kYXRlLmMg dGVzdHMvbGlibnRwL3J1bi1sZnBmdW5jLmMgdGVzdHMvbGlibnRwL3J1bi1sZnB0b3N0ci5jIHRl c3RzL2xpYm50cC9ydW4tbW9kZXRvYS5jIHRlc3RzL2xpYm50cC9ydW4tbXN5c2xvZy5jIHRlc3Rz L2xpYm50cC9ydW4tbmV0b2YuYyB0ZXN0cy9saWJudHAvcnVuLW51bXRvYS5jIHRlc3RzL2xpYm50 cC9ydW4tb2N0dG9pbnQuYyB0ZXN0cy9saWJudHAvcnVuLXByZXR0eWRhdGUuYyB0ZXN0cy9saWJu dHAvcnVuLXJlYWxwYXRoLmMgdGVzdHMvbGlibnRwL3J1bi1yZWN2YnVmZi5jIHRlc3RzL2xpYm50 cC9ydW4tcmVmaWRzbWVhci5jIHRlc3RzL2xpYm50cC9ydW4tcmVmbnVtdG9hLmMgdGVzdHMvbGli bnRwL3J1bi1zYnByaW50Zi5jIHRlc3RzL2xpYm50cC9ydW4tc2ZwdG9zdHIuYyB0ZXN0cy9saWJu dHAvcnVuLXNvY2t0b2EuYyB0ZXN0cy9saWJudHAvcnVuLXNzbF9pbml0LmMgdGVzdHMvbGlibnRw L3J1bi1zdGF0ZXN0ci5jIHRlc3RzL2xpYm50cC9ydW4tc3RydG9sZnAuYyB0ZXN0cy9saWJudHAv cnVuLXRpbWVzcGVjb3BzLmMgdGVzdHMvbGlibnRwL3J1bi10aW1ldmFsb3BzLmMgdGVzdHMvbGli bnRwL3J1bi10c2FmZW1lbWNtcC5jIHRlc3RzL2xpYm50cC9ydW4tdHN0b3R2LmMgdGVzdHMvbGli bnRwL3J1bi10dnRvdHMuYyB0ZXN0cy9saWJudHAvcnVuLXVnbHlkYXRlLmMgdGVzdHMvbGlibnRw L3J1bi12aTY0b3BzLmMgdGVzdHMvbGlibnRwL3J1bi15bWQyeWQuYyB0ZXN0cy9udHBkL3J1bi1s ZWFwc2VjLmMgdGVzdHMvbnRwZC9ydW4tbnRwX3ByaW9fcS5jIHRlc3RzL250cGQvcnVuLW50cF9y ZXN0cmljdC5jIHRlc3RzL250cGQvcnVuLW50cF91dGlsLmMgdGVzdHMvbnRwZC9ydW4tcmNfY21k bGVuZ3RoLmMgdGVzdHMvbnRwZC9ydW4tdC1udHBfc2Nhbm5lci5jIHRlc3RzL250cGQvcnVuLXQt bnRwX3NpZ25kLmMgdGVzdHMvbnRwcS9ydW4tdC1udHBxLmMgdGVzdHMvc2FuZGJveC9ydW4tYnVn LTI4MDMuYyB0ZXN0cy9zYW5kYm94L3J1bi1tb2RldG9hLmMgdGVzdHMvc2FuZGJveC9ydW4tdWds eWRhdGUuYyB0ZXN0cy9zYW5kYm94L3J1bi11dC0yODAzLmMgdGVzdHMvc2VjLTI4NTMvcnVuLXNl Yy0yODUzLmM+ClRvdWNoaW5nIDwgbnRwZC9udHAuY29uZi41bWFuIG50cGQvbnRwLmNvbmYuNW1k b2MgbnRwZC9udHAuY29uZi5tYW4uaW4gbnRwZC9udHAuY29uZi5tZG9jLmluIG50cGQvbnRwLmNv bmYudGV4aSBudHBkL250cC5rZXlzLjVtYW4gbnRwZC9udHAua2V5cy41bWRvYyBudHBkL250cC5r ZXlzLm1hbi5pbiBudHBkL250cC5rZXlzLm1kb2MuaW4gbnRwZC9udHAua2V5cy50ZXhpIG50cGQv bnRwZC1vcHRzLmMgbnRwZC9udHBkLW9wdHMuaCBudHBkL250cGQuMW50cGRtYW4gbnRwZC9udHBk LjFudHBkbWRvYyBudHBkL250cGQuYyBudHBkL250cGQubWFuLmluIG50cGQvbnRwZC5tZG9jLmlu IG50cGQvbnRwZC50ZXhpIG50cGQvbnRwZHNpbS1vcHRzLmMgbnRwZC9udHBkc2ltLW9wdHMuaCBu dHBkL250cGRzaW0tb3B0cy5tZW51IG50cGQvbnRwZHNpbS1vcHRzLnRleGkgbnRwZC9udHBkc2lt LW9wdHMuYyBudHBkL250cGRzaW0tb3B0cy5oIG50cGQvbnRwZHNpbS1vcHRzLm1lbnUgbnRwZC9u dHBkc2ltLW9wdHMudGV4aSBudHBkYy9udHBkYy1sYXlvdXQuYyBudHBkYy9udHBkYy1vcHRzLmMg bnRwZGMvbnRwZGMtb3B0cy5oIG50cGRjL250cGRjLjFudHBkY21hbiBudHBkYy9udHBkYy4xbnRw ZGNtZG9jIG50cGRjL250cGRjLmMgbnRwZGMvbnRwZGMuaCBudHBkYy9udHBkYy5tYW4uaW4gbnRw ZGMvbnRwZGMubWRvYy5pbiBudHBkYy9udHBkYy50ZXhpIG50cGRjL250cGRjX29wcy5jIG50cHEv bnRwcS1vcHRzLmMgbnRwcS9udHBxLW9wdHMuaCBudHBxL250cHEtc3Vicy5jIG50cHEvbnRwcS4x bnRwcW1hbiBudHBxL250cHEuMW50cHFtZG9jIG50cHEvbnRwcS5jIG50cHEvbnRwcS5oIG50cHEv bnRwcS5tYW4uaW4gbnRwcS9udHBxLm1kb2MuaW4gbnRwcS9udHBxLnRleGkgbnRwc25tcGQvbnRw c25tcGQtb3B0cy5jIG50cHNubXBkL250cHNubXBkLW9wdHMuaCBudHBzbm1wZC9udHBzbm1wZC4x bnRwc25tcGRtYW4gbnRwc25tcGQvbnRwc25tcGQuMW50cHNubXBkbWRvYyBudHBzbm1wZC9udHBz bm1wZC5jIG50cHNubXBkL250cHNubXBkLm1hbi5pbiBudHBzbm1wZC9udHBzbm1wZC5tZG9jLmlu IG50cHNubXBkL250cHNubXBkLnRleGkgc2NyaXB0cy9jYWxjX3RpY2thZGovY2FsY190aWNrYWRq LW9wdHMgc2NyaXB0cy9jYWxjX3RpY2thZGovY2FsY190aWNrYWRqLjFjYWxjX3RpY2thZGptYW4g c2NyaXB0cy9jYWxjX3RpY2thZGovY2FsY190aWNrYWRqLjFjYWxjX3RpY2thZGptZG9jIHNjcmlw dHMvY2FsY190aWNrYWRqL2NhbGNfdGlja2Fkai5tYW4uaW4gc2NyaXB0cy9jYWxjX3RpY2thZGov Y2FsY190aWNrYWRqLm1kb2MuaW4gc2NyaXB0cy9jYWxjX3RpY2thZGovY2FsY190aWNrYWRqLnRl eGkgc2NyaXB0cy9udHAtd2FpdC9udHAtd2FpdC1vcHRzIHNjcmlwdHMvbnRwLXdhaXQvbnRwLXdh aXQuMW50cC13YWl0bWFuIHNjcmlwdHMvbnRwLXdhaXQvbnRwLXdhaXQuMW50cC13YWl0bWRvYyBz Y3JpcHRzL250cC13YWl0L250cC13YWl0Lm1hbi5pbiBzY3JpcHRzL250cC13YWl0L250cC13YWl0 Lm1kb2MuaW4gc2NyaXB0cy9udHAtd2FpdC9udHAtd2FpdC50ZXhpIHNjcmlwdHMvbnRwc3dlZXAv bnRwc3dlZXAtb3B0cyBzY3JpcHRzL250cHN3ZWVwL250cHN3ZWVwLjFudHBzd2VlcG1hbiBzY3Jp cHRzL250cHN3ZWVwL250cHN3ZWVwLjFudHBzd2VlcG1kb2Mgc2NyaXB0cy9udHBzd2VlcC9udHBz d2VlcC5tYW4uaW4gc2NyaXB0cy9udHBzd2VlcC9udHBzd2VlcC5tZG9jLmluIHNjcmlwdHMvbnRw c3dlZXAvbnRwc3dlZXAudGV4aSBzY3JpcHRzL250cHRyYWNlL250cHRyYWNlLW9wdHMgc2NyaXB0 cy9udHB0cmFjZS9udHB0cmFjZS4xbnRwdHJhY2VtYW4gc2NyaXB0cy9udHB0cmFjZS9udHB0cmFj ZS4xbnRwdHJhY2VtZG9jIHNjcmlwdHMvbnRwdHJhY2UvbnRwdHJhY2UubWFuLmluIHNjcmlwdHMv bnRwdHJhY2UvbnRwdHJhY2UubWRvYy5pbiBzY3JpcHRzL250cHRyYWNlL250cHRyYWNlLnRleGkg c2NyaXB0cy9wbG90X3N1bW1hcnktb3B0cyBzY3JpcHRzL3Bsb3Rfc3VtbWFyeS4xcGxvdF9zdW1t YXJ5bWFuIHNjcmlwdHMvcGxvdF9zdW1tYXJ5LjFwbG90X3N1bW1hcnltZG9jIHNjcmlwdHMvcGxv dF9zdW1tYXJ5Lm1hbi5pbiBzY3JpcHRzL3Bsb3Rfc3VtbWFyeS5tZG9jLmluIHNjcmlwdHMvcGxv dF9zdW1tYXJ5LnRleGkgc2NyaXB0cy9zdW1tYXJ5LW9wdHMgc2NyaXB0cy9zdW1tYXJ5LjFzdW1t YXJ5bWFuIHNjcmlwdHMvc3VtbWFyeS4xc3VtbWFyeW1kb2Mgc2NyaXB0cy9zdW1tYXJ5Lm1hbi5p biBzY3JpcHRzL3N1bW1hcnkubWRvYy5pbiBzY3JpcHRzL3N1bW1hcnkudGV4aSBzY3JpcHRzL3Vw ZGF0ZS1sZWFwL3VwZGF0ZS1sZWFwLW9wdHMgc2NyaXB0cy91cGRhdGUtbGVhcC91cGRhdGUtbGVh cC4xdXBkYXRlLWxlYXBtYW4gc2NyaXB0cy91cGRhdGUtbGVhcC91cGRhdGUtbGVhcC4xdXBkYXRl LWxlYXBtZG9jIHNjcmlwdHMvdXBkYXRlLWxlYXAvdXBkYXRlLWxlYXAubWFuLmluIHNjcmlwdHMv dXBkYXRlLWxlYXAvdXBkYXRlLWxlYXAubWRvYy5pbiBzY3JpcHRzL3VwZGF0ZS1sZWFwL3VwZGF0 ZS1sZWFwLnRleGkgc250cC9zbnRwLW9wdHMuYyBzbnRwL3NudHAtb3B0cy5oIHNudHAvc250cC4x c250cG1hbiBzbnRwL3NudHAuMXNudHBtZG9jIHNudHAvc250cC5jIHNudHAvc250cC5tYW4uaW4g c250cC9zbnRwLm1kb2MuaW4gc250cC9zbnRwLnRleGkgdXRpbC9udHAta2V5Z2VuLW9wdHMuYyB1 dGlsL250cC1rZXlnZW4tb3B0cy5oIHV0aWwvbnRwLWtleWdlbi4xbnRwLWtleWdlbm1hbiB1dGls L250cC1rZXlnZW4uMW50cC1rZXlnZW5tZG9jIHV0aWwvbnRwLWtleWdlbi5jIHV0aWwvbnRwLWtl eWdlbi5tYW4uaW4gdXRpbC9udHAta2V5Z2VuLm1kb2MuaW4gdXRpbC9udHAta2V5Z2VuLnRleGk+ ClRvdWNoaW5nIDwgbnRwZC9pbnZva2UtbnRwLmNvbmYubWVudSBudHBkL2ludm9rZS1udHAuY29u Zi50ZXhpIG50cGQvaW52b2tlLW50cC5rZXlzLm1lbnUgbnRwZC9pbnZva2UtbnRwLmtleXMudGV4 aSBudHBkL2ludm9rZS1udHBkLm1lbnUgbnRwZC9pbnZva2UtbnRwZC50ZXhpIG50cGQvaW52b2tl LW50cC5jb25mLm1lbnUgbnRwZC9pbnZva2UtbnRwLmNvbmYudGV4aSBudHBkL2ludm9rZS1udHAu a2V5cy5tZW51IG50cGQvaW52b2tlLW50cC5rZXlzLnRleGkgbnRwZC9pbnZva2UtbnRwZC5tZW51 IG50cGQvaW52b2tlLW50cGQudGV4aSBudHBkL2ludm9rZS1udHAuY29uZi5tZW51IG50cGQvaW52 b2tlLW50cC5jb25mLnRleGkgbnRwZC9pbnZva2UtbnRwLmtleXMubWVudSBudHBkL2ludm9rZS1u dHAua2V5cy50ZXhpIG50cGQvaW52b2tlLW50cGQubWVudSBudHBkL2ludm9rZS1udHBkLnRleGkg bnRwZC9pbnZva2UtbnRwLmNvbmYubWVudSBudHBkL2ludm9rZS1udHAuY29uZi50ZXhpIG50cGQv aW52b2tlLW50cC5rZXlzLm1lbnUgbnRwZC9pbnZva2UtbnRwLmtleXMudGV4aSBudHBkL2ludm9r ZS1udHBkLm1lbnUgbnRwZC9pbnZva2UtbnRwZC50ZXhpIG50cGRjL2ludm9rZS1udHBkYy5tZW51 IG50cGRjL2ludm9rZS1udHBkYy50ZXhpIG50cHEvaW52b2tlLW50cHEubWVudSBudHBxL2ludm9r ZS1udHBxLnRleGkgbnRwc25tcGQvaW52b2tlLW50cHNubXBkLm1lbnUgbnRwc25tcGQvaW52b2tl LW50cHNubXBkLnRleGkgc2NyaXB0cy9jYWxjX3RpY2thZGovaW52b2tlLWNhbGNfdGlja2Fkai5t ZW51IHNjcmlwdHMvY2FsY190aWNrYWRqL2ludm9rZS1jYWxjX3RpY2thZGoudGV4aSBzY3JpcHRz L250cC13YWl0L2ludm9rZS1udHAtd2FpdC5tZW51IHNjcmlwdHMvbnRwLXdhaXQvaW52b2tlLW50 cC13YWl0LnRleGkgc2NyaXB0cy9udHBzd2VlcC9pbnZva2UtbnRwc3dlZXAubWVudSBzY3JpcHRz L250cHN3ZWVwL2ludm9rZS1udHBzd2VlcC50ZXhpIHNjcmlwdHMvbnRwdHJhY2UvaW52b2tlLW50 cHRyYWNlLm1lbnUgc2NyaXB0cy9udHB0cmFjZS9pbnZva2UtbnRwdHJhY2UudGV4aSBzY3JpcHRz L2ludm9rZS1wbG90X3N1bW1hcnkubWVudSBzY3JpcHRzL2ludm9rZS1wbG90X3N1bW1hcnkudGV4 aSBzY3JpcHRzL2ludm9rZS1zdW1tYXJ5Lm1lbnUgc2NyaXB0cy9pbnZva2Utc3VtbWFyeS50ZXhp IHNjcmlwdHMvaW52b2tlLXBsb3Rfc3VtbWFyeS5tZW51IHNjcmlwdHMvaW52b2tlLXBsb3Rfc3Vt bWFyeS50ZXhpIHNjcmlwdHMvaW52b2tlLXN1bW1hcnkubWVudSBzY3JpcHRzL2ludm9rZS1zdW1t YXJ5LnRleGkgc2NyaXB0cy91cGRhdGUtbGVhcC9pbnZva2UtdXBkYXRlLWxlYXAubWVudSBzY3Jp cHRzL3VwZGF0ZS1sZWFwL2ludm9rZS11cGRhdGUtbGVhcC50ZXhpIHNudHAvaW52b2tlLXNudHAu bWVudSBzbnRwL2ludm9rZS1zbnRwLnRleGkgdXRpbC9pbnZva2UtbnRwLWtleWdlbi5tZW51IHV0 aWwvaW52b2tlLW50cC1rZXlnZW4udGV4aT4KVG91Y2hpbmcgPCBudHBkL250cC5jb25mLmh0bWwg bnRwZC9udHAua2V5cy5odG1sIG50cGQvbnRwZC5odG1sIG50cGRjL250cGRjLmh0bWwgbnRwcS9u dHBxLmh0bWwgbnRwc25tcGQvbnRwc25tcGQuaHRtbCBzY3JpcHRzL2NhbGNfdGlja2Fkai9jYWxj X3RpY2thZGouaHRtbCBzY3JpcHRzL250cC13YWl0L250cC13YWl0Lmh0bWwgc2NyaXB0cy9udHBz d2VlcC9udHBzd2VlcC5odG1sIHNjcmlwdHMvbnRwdHJhY2UvbnRwdHJhY2UuaHRtbCBzY3JpcHRz L3Bsb3Rfc3VtbWFyeS5odG1sIHNjcmlwdHMvc3VtbWFyeS5odG1sIHNjcmlwdHMvdXBkYXRlLWxl YXAvdXBkYXRlLWxlYXAuaHRtbCBzbnRwL3NudHAuaHRtbCB1dGlsL250cC1rZXlnZW4uaHRtbD4K YXV0b3JlY29uZjogZXhwb3J0IFdBUk5JTkdTPQphdXRvcmVjb25mOiBFbnRlcmluZyBkaXJlY3Rv cnkgJy4nCmF1dG9yZWNvbmY6IGNvbmZpZ3VyZS5hYzogbm90IHVzaW5nIEdldHRleHQKYXV0b3Jl Y29uZjogcnVubmluZzogYWNsb2NhbCAtSSBzbnRwL200IC1JIHNudHAvbGliZXZlbnQvbTQgLUkg c250cC9saWJvcHRzL200CmF1dG9yZWNvbmY6IGNvbmZpZ3VyZS5hYzogdHJhY2luZwphdXRvcmVj b25mOiBjb25maWd1cmUuYWM6IGFkZGluZyBzdWJkaXJlY3Rvcnkgc250cCB0byBhdXRvcmVjb25m CmF1dG9yZWNvbmY6IEVudGVyaW5nIGRpcmVjdG9yeSAnc250cCcKYXV0b3JlY29uZjogY29uZmln dXJlLmFjOiBub3QgdXNpbmcgR2V0dGV4dAphdXRvcmVjb25mOiBydW5uaW5nOiBhY2xvY2FsIC1J IG00IC1JIGxpYmV2ZW50L200IC1JIGxpYm9wdHMvbTQKYXV0b3JlY29uZjogY29uZmlndXJlLmFj OiB0cmFjaW5nCmF1dG9yZWNvbmY6IGNvbmZpZ3VyZS5hYzogYWRkaW5nIHN1YmRpcmVjdG9yeSBs aWJldmVudCB0byBhdXRvcmVjb25mCmF1dG9yZWNvbmY6IEVudGVyaW5nIGRpcmVjdG9yeSAnbGli ZXZlbnQnCmF1dG9yZWNvbmY6IGNvbmZpZ3VyZS5hYzogbm90IHVzaW5nIEdldHRleHQKYXV0b3Jl Y29uZjogcnVubmluZzogYWNsb2NhbCAtSSBtNAphdXRvcmVjb25mOiBjb25maWd1cmUuYWM6IHRy YWNpbmcKYXV0b3JlY29uZjogY29uZmlndXJlLmFjOiBjcmVhdGluZyBkaXJlY3RvcnkgYnVpbGQt YXV4CmF1dG9yZWNvbmY6IHJ1bm5pbmc6IGxpYnRvb2xpemUgLS1jb3B5CmxpYnRvb2xpemU6IHB1 dHRpbmcgYXV4aWxpYXJ5IGZpbGVzIGluIEFDX0NPTkZJR19BVVhfRElSLCAnYnVpbGQtYXV4Jy4K bGlidG9vbGl6ZTogY29weWluZyBmaWxlICdidWlsZC1hdXgvbHRtYWluLnNoJwpsaWJ0b29saXpl OiBwdXR0aW5nIG1hY3JvcyBpbiBBQ19DT05GSUdfTUFDUk9fRElSUywgJ200Jy4KbGlidG9vbGl6 ZTogY29weWluZyBmaWxlICdtNC9saWJ0b29sLm00JwpsaWJ0b29saXplOiBjb3B5aW5nIGZpbGUg J200L2x0b3B0aW9ucy5tNCcKbGlidG9vbGl6ZTogY29weWluZyBmaWxlICdtNC9sdHN1Z2FyLm00 JwpsaWJ0b29saXplOiBjb3B5aW5nIGZpbGUgJ200L2x0dmVyc2lvbi5tNCcKbGlidG9vbGl6ZTog Y29weWluZyBmaWxlICdtNC9sdH5vYnNvbGV0ZS5tNCcKYXV0b3JlY29uZjogY29uZmlndXJlLmFj OiBub3QgdXNpbmcgSW50bHRvb2wKYXV0b3JlY29uZjogY29uZmlndXJlLmFjOiBub3QgdXNpbmcg R3RrZG9jCmF1dG9yZWNvbmY6IHJ1bm5pbmc6IGFjbG9jYWwgLUkgbTQKYXV0b3JlY29uZjogcnVu bmluZzogL3Vzci9sb2NhbC9iaW4vYXV0b2NvbmYKY29uZmlndXJlLmFjOjQ2OiB3YXJuaW5nOiBU aGUgbWFjcm8gJ0FDX1BST0dfR0NDX1RSQURJVElPTkFMJyBpcyBvYnNvbGV0ZS4KY29uZmlndXJl LmFjOjQ2OiBZb3Ugc2hvdWxkIHJ1biBhdXRvdXBkYXRlLgouLi9saWIvYXV0b2NvbmYvYy5tNDox Njc2OiBBQ19QUk9HX0dDQ19UUkFESVRJT05BTCBpcyBleHBhbmRlZCBmcm9tLi4uCmNvbmZpZ3Vy ZS5hYzo0NjogdGhlIHRvcCBsZXZlbApjb25maWd1cmUuYWM6MzU3OiB3YXJuaW5nOiBUaGUgbWFj cm8gJ0FDX0hFQURFUl9USU1FJyBpcyBvYnNvbGV0ZS4KY29uZmlndXJlLmFjOjM1NzogWW91IHNo b3VsZCBydW4gYXV0b3VwZGF0ZS4KLi4vbGliL2F1dG9jb25mL2hlYWRlcnMubTQ6NzAyOiBBQ19I RUFERVJfVElNRSBpcyBleHBhbmRlZCBmcm9tLi4uCmNvbmZpZ3VyZS5hYzozNTc6IHRoZSB0b3Ag bGV2ZWwKY29uZmlndXJlLmFjOjgwNTogd2FybmluZzogVGhlIG1hY3JvICdBQ19UUllfTElOSycg aXMgb2Jzb2xldGUuCmNvbmZpZ3VyZS5hYzo4MDU6IFlvdSBzaG91bGQgcnVuIGF1dG91cGRhdGUu Ci4uL2xpYi9hdXRvY29uZi9nZW5lcmFsLm00OjI5MTg6IEFDX1RSWV9MSU5LIGlzIGV4cGFuZGVk IGZyb20uLi4KbTQvYWN4X3B0aHJlYWQubTQ6ODY6IEFDWF9QVEhSRUFEIGlzIGV4cGFuZGVkIGZy b20uLi4KY29uZmlndXJlLmFjOjgwNTogdGhlIHRvcCBsZXZlbApjb25maWd1cmUuYWM6MTAxMjog d2FybmluZzogQUNfT1VUUFVUIHNob3VsZCBiZSB1c2VkIHdpdGhvdXQgYXJndW1lbnRzLgpjb25m aWd1cmUuYWM6MTAxMjogWW91IHNob3VsZCBydW4gYXV0b3VwZGF0ZS4KYXV0b3JlY29uZjogcnVu bmluZzogL3Vzci9sb2NhbC9iaW4vYXV0b2hlYWRlcgphdXRvcmVjb25mOiBydW5uaW5nOiBhdXRv bWFrZSAtLWFkZC1taXNzaW5nIC0tY29weSAtLW5vLWZvcmNlCmNvbmZpZ3VyZS5hYzoyNDogaW5z dGFsbGluZyAnYnVpbGQtYXV4L2NvbXBpbGUnCmNvbmZpZ3VyZS5hYzoyNjogaW5zdGFsbGluZyAn YnVpbGQtYXV4L2NvbmZpZy5ndWVzcycKY29uZmlndXJlLmFjOjI2OiBpbnN0YWxsaW5nICdidWls ZC1hdXgvY29uZmlnLnN1YicKY29uZmlndXJlLmFjOjE0OiBpbnN0YWxsaW5nICdidWlsZC1hdXgv aW5zdGFsbC1zaCcKY29uZmlndXJlLmFjOjE0OiBpbnN0YWxsaW5nICdidWlsZC1hdXgvbWlzc2lu ZycKTWFrZWZpbGUuYW06IGluc3RhbGxpbmcgJ2J1aWxkLWF1eC9kZXBjb21wJwpwYXJhbGxlbC10 ZXN0czogaW5zdGFsbGluZyAnYnVpbGQtYXV4L3Rlc3QtZHJpdmVyJwphdXRvcmVjb25mOiBMZWF2 aW5nIGRpcmVjdG9yeSAnbGliZXZlbnQnCmF1dG9yZWNvbmY6IHJ1bm5pbmc6IGxpYnRvb2xpemUg LS1jb3B5CmxpYnRvb2xpemU6IHB1dHRpbmcgbWFjcm9zIGluIEFDX0NPTkZJR19NQUNST19ESVJT LCAnbTQnLgpsaWJ0b29saXplOiBjb3B5aW5nIGZpbGUgJ200L2xpYnRvb2wubTQnCmxpYnRvb2xp emU6IGNvcHlpbmcgZmlsZSAnbTQvbHRvcHRpb25zLm00JwpsaWJ0b29saXplOiBjb3B5aW5nIGZp bGUgJ200L2x0c3VnYXIubTQnCmxpYnRvb2xpemU6IGNvcHlpbmcgZmlsZSAnbTQvbHR2ZXJzaW9u Lm00JwpsaWJ0b29saXplOiBjb3B5aW5nIGZpbGUgJ200L2x0fm9ic29sZXRlLm00JwphdXRvcmVj b25mOiBjb25maWd1cmUuYWM6IG5vdCB1c2luZyBJbnRsdG9vbAphdXRvcmVjb25mOiBjb25maWd1 cmUuYWM6IG5vdCB1c2luZyBHdGtkb2MKYXV0b3JlY29uZjogcnVubmluZzogYWNsb2NhbCAtSSBt NCAtSSBsaWJldmVudC9tNCAtSSBsaWJvcHRzL200CmF1dG9yZWNvbmY6IHJ1bm5pbmc6IC91c3Iv bG9jYWwvYmluL2F1dG9jb25mCmNvbmZpZ3VyZS5hYzo1Mjogd2FybmluZzogVGhlIG1hY3JvICdB Q19DT05GSUdfSEVBREVSJyBpcyBvYnNvbGV0ZS4KY29uZmlndXJlLmFjOjUyOiBZb3Ugc2hvdWxk IHJ1biBhdXRvdXBkYXRlLgouLi9saWIvYXV0b2NvbmYvc3RhdHVzLm00OjcxOTogQUNfQ09ORklH X0hFQURFUiBpcyBleHBhbmRlZCBmcm9tLi4uCmNvbmZpZ3VyZS5hYzo1MjogdGhlIHRvcCBsZXZl bApjb25maWd1cmUuYWM6NTY6IHdhcm5pbmc6IFRoZSBtYWNybyAnQUNfUFJPR19DQ19TVERDJyBp cyBvYnNvbGV0ZS4KY29uZmlndXJlLmFjOjU2OiBZb3Ugc2hvdWxkIHJ1biBhdXRvdXBkYXRlLgou Li9saWIvYXV0b2NvbmYvYy5tNDoxNjY5OiBBQ19QUk9HX0NDX1NUREMgaXMgZXhwYW5kZWQgZnJv bS4uLgptNC9udHBfY29tcGlsZXIubTQ6MzogTlRQX0NPTVBJTEVSIGlzIGV4cGFuZGVkIGZyb20u Li4KY29uZmlndXJlLmFjOjU2OiB0aGUgdG9wIGxldmVsCmNvbmZpZ3VyZS5hYzo2Mzogd2Fybmlu ZzogVGhlIG1hY3JvICdBQ19UUllfTElOSycgaXMgb2Jzb2xldGUuCmNvbmZpZ3VyZS5hYzo2Mzog WW91IHNob3VsZCBydW4gYXV0b3VwZGF0ZS4KLi4vbGliL2F1dG9jb25mL2dlbmVyYWwubTQ6Mjkx ODogQUNfVFJZX0xJTksgaXMgZXhwYW5kZWQgZnJvbS4uLgouLi9saWIvbTRzdWdhci9tNHNoLm00 OjY5NzogQVNfSUYgaXMgZXhwYW5kZWQgZnJvbS4uLgouLi9saWIvYXV0b2NvbmYvZ2VuZXJhbC5t NDoyOTc5OiBBQ19SVU5fSUZFTFNFIGlzIGV4cGFuZGVkIGZyb20uLi4KLi4vbGliL200c3VnYXIv bTRzaC5tNDo2OTA6IF9BU19JRl9FTFNFIGlzIGV4cGFuZGVkIGZyb20uLi4KLi4vbGliL200c3Vn YXIvbTRzaC5tNDo2OTc6IEFTX0lGIGlzIGV4cGFuZGVkIGZyb20uLi4KLi4vbGliL2F1dG9jb25m L2dlbmVyYWwubTQ6MjI0OTogQUNfQ0FDSEVfVkFMIGlzIGV4cGFuZGVkIGZyb20uLi4KLi4vbGli L2F1dG9jb25mL2dlbmVyYWwubTQ6MjI3MDogQUNfQ0FDSEVfQ0hFQ0sgaXMgZXhwYW5kZWQgZnJv bS4uLgptNC9vcGVubGRhcC10aHJlYWQtY2hlY2subTQ6MjM6IE9MX1RIUkVBRF9DSEVDSyBpcyBl eHBhbmRlZCBmcm9tLi4uCm00L250cF9saWJudHAubTQ6OTogTlRQX0xJQk5UUCBpcyBleHBhbmRl ZCBmcm9tLi4uCmNvbmZpZ3VyZS5hYzo2MzogdGhlIHRvcCBsZXZlbApjb25maWd1cmUuYWM6OTQ6 IHdhcm5pbmc6IFRoZSBtYWNybyAnQUNfSEVBREVSX1NUREMnIGlzIG9ic29sZXRlLgpjb25maWd1 cmUuYWM6OTQ6IFlvdSBzaG91bGQgcnVuIGF1dG91cGRhdGUuCi4uL2xpYi9hdXRvY29uZi9oZWFk ZXJzLm00OjY2MzogQUNfSEVBREVSX1NUREMgaXMgZXhwYW5kZWQgZnJvbS4uLgpsaWJvcHRzL200 L2xpYm9wdHMubTQ6NDogSU5WT0tFX0xJQk9QVFNfTUFDUk9TX0ZJUlNUIGlzIGV4cGFuZGVkIGZy b20uLi4KbGlib3B0cy9tNC9saWJvcHRzLm00OjQ3NTogTElCT1BUU19DSEVDS19DT01NT04gaXMg ZXhwYW5kZWQgZnJvbS4uLgpsaWJvcHRzL200L2xpYm9wdHMubTQ6NTc1OiBMSUJPUFRTX0NIRUNL IGlzIGV4cGFuZGVkIGZyb20uLi4KY29uZmlndXJlLmFjOjk0OiB0aGUgdG9wIGxldmVsCmNvbmZp Z3VyZS5hYzo5NDogd2FybmluZzogVGhlIG1hY3JvICdBQ19IRUxQX1NUUklORycgaXMgb2Jzb2xl dGUuCmNvbmZpZ3VyZS5hYzo5NDogWW91IHNob3VsZCBydW4gYXV0b3VwZGF0ZS4KLi4vbGliL2F1 dG9jb25mL2dlbmVyYWwubTQ6MjA0OiBBQ19IRUxQX1NUUklORyBpcyBleHBhbmRlZCBmcm9tLi4u CmxpYm9wdHMvbTQvbGlib3B0cy5tNDo0NzU6IExJQk9QVFNfQ0hFQ0tfQ09NTU9OIGlzIGV4cGFu ZGVkIGZyb20uLi4KbGlib3B0cy9tNC9saWJvcHRzLm00OjU3NTogTElCT1BUU19DSEVDSyBpcyBl eHBhbmRlZCBmcm9tLi4uCmNvbmZpZ3VyZS5hYzo5NDogdGhlIHRvcCBsZXZlbApjb25maWd1cmUu YWM6MTAzOiB3YXJuaW5nOiBUaGUgbWFjcm8gJ0FDX0hFTFBfU1RSSU5HJyBpcyBvYnNvbGV0ZS4K Y29uZmlndXJlLmFjOjEwMzogWW91IHNob3VsZCBydW4gYXV0b3VwZGF0ZS4KLi4vbGliL2F1dG9j b25mL2dlbmVyYWwubTQ6MjA0OiBBQ19IRUxQX1NUUklORyBpcyBleHBhbmRlZCBmcm9tLi4uCi4u L2xpYi9hdXRvY29uZi9nZW5lcmFsLm00OjE1MzQ6IEFDX0FSR19FTkFCTEUgaXMgZXhwYW5kZWQg ZnJvbS4uLgptNC9udHBfbGliZXZlbnQubTQ6MzE6IE5UUF9FTkFCTEVfTE9DQUxfTElCRVZFTlQg aXMgZXhwYW5kZWQgZnJvbS4uLgptNC9udHBfbGliZXZlbnQubTQ6NjA6IE5UUF9MSUJFVkVOVF9D SEVDS19OT0JVSUxEIGlzIGV4cGFuZGVkIGZyb20uLi4KbTQvbnRwX2xpYmV2ZW50Lm00OjE2NDog TlRQX0xJQkVWRU5UX0NIRUNLIGlzIGV4cGFuZGVkIGZyb20uLi4KY29uZmlndXJlLmFjOjEwMzog dGhlIHRvcCBsZXZlbAphdXRvcmVjb25mOiBydW5uaW5nOiAvdXNyL2xvY2FsL2Jpbi9hdXRvaGVh ZGVyCmF1dG9yZWNvbmY6IHJ1bm5pbmc6IGF1dG9tYWtlIC0tYWRkLW1pc3NpbmcgLS1jb3B5IC0t bm8tZm9yY2UKY29uZmlndXJlLmFjOjYxOiBpbnN0YWxsaW5nICdsaWJldmVudC9idWlsZC1hdXgv YXItbGliJwphdXRvcmVjb25mOiBMZWF2aW5nIGRpcmVjdG9yeSAnc250cCcKYXV0b3JlY29uZjog cnVubmluZzogbGlidG9vbGl6ZSAtLWNvcHkKYXV0b3JlY29uZjogY29uZmlndXJlLmFjOiBub3Qg dXNpbmcgSW50bHRvb2wKYXV0b3JlY29uZjogY29uZmlndXJlLmFjOiBub3QgdXNpbmcgR3RrZG9j CmF1dG9yZWNvbmY6IHJ1bm5pbmc6IGFjbG9jYWwgLUkgc250cC9tNCAtSSBzbnRwL2xpYmV2ZW50 L200IC1JIHNudHAvbGlib3B0cy9tNAphdXRvcmVjb25mOiBydW5uaW5nOiAvdXNyL2xvY2FsL2Jp bi9hdXRvY29uZgpjb25maWd1cmUuYWM6ODI6IHdhcm5pbmc6IFRoZSBtYWNybyAnQUNfUFJPR19D Q19TVERDJyBpcyBvYnNvbGV0ZS4KY29uZmlndXJlLmFjOjgyOiBZb3Ugc2hvdWxkIHJ1biBhdXRv dXBkYXRlLgouLi9saWIvYXV0b2NvbmYvYy5tNDoxNjY5OiBBQ19QUk9HX0NDX1NUREMgaXMgZXhw YW5kZWQgZnJvbS4uLgpzbnRwL200L250cF9jb21waWxlci5tNDozOiBOVFBfQ09NUElMRVIgaXMg ZXhwYW5kZWQgZnJvbS4uLgpjb25maWd1cmUuYWM6ODI6IHRoZSB0b3AgbGV2ZWwKY29uZmlndXJl LmFjOjg2OiB3YXJuaW5nOiBUaGUgbWFjcm8gJ0FDX1BST0dfQ0NfQzk5JyBpcyBvYnNvbGV0ZS4K Y29uZmlndXJlLmFjOjg2OiBZb3Ugc2hvdWxkIHJ1biBhdXRvdXBkYXRlLgouLi9saWIvYXV0b2Nv bmYvYy5tNDoxNjYyOiBBQ19QUk9HX0NDX0M5OSBpcyBleHBhbmRlZCBmcm9tLi4uCnNudHAvbTQv YXhfYzk5X3N0cnVjdF9pbml0Lm00OjQwOiBBWF9DOTlfU1RSVUNUX0lOSVQgaXMgZXhwYW5kZWQg ZnJvbS4uLgpjb25maWd1cmUuYWM6ODY6IHRoZSB0b3AgbGV2ZWwKY29uZmlndXJlLmFjOjExNjog d2FybmluZzogVGhlIG1hY3JvICdBQ19IRUFERVJfU1REQycgaXMgb2Jzb2xldGUuCmNvbmZpZ3Vy ZS5hYzoxMTY6IFlvdSBzaG91bGQgcnVuIGF1dG91cGRhdGUuCi4uL2xpYi9hdXRvY29uZi9oZWFk ZXJzLm00OjY2MzogQUNfSEVBREVSX1NUREMgaXMgZXhwYW5kZWQgZnJvbS4uLgpzbnRwL2xpYm9w dHMvbTQvbGlib3B0cy5tNDo0OiBJTlZPS0VfTElCT1BUU19NQUNST1NfRklSU1QgaXMgZXhwYW5k ZWQgZnJvbS4uLgpzbnRwL2xpYm9wdHMvbTQvbGlib3B0cy5tNDo0NzU6IExJQk9QVFNfQ0hFQ0tf Q09NTU9OIGlzIGV4cGFuZGVkIGZyb20uLi4Kc250cC9saWJvcHRzL200L2xpYm9wdHMubTQ6NTY2 OiBMSUJPUFRTX0NIRUNLX05PQlVJTEQgaXMgZXhwYW5kZWQgZnJvbS4uLgpjb25maWd1cmUuYWM6 MTE2OiB0aGUgdG9wIGxldmVsCmNvbmZpZ3VyZS5hYzoxMTY6IHdhcm5pbmc6IFRoZSBtYWNybyAn QUNfSEVMUF9TVFJJTkcnIGlzIG9ic29sZXRlLgpjb25maWd1cmUuYWM6MTE2OiBZb3Ugc2hvdWxk IHJ1biBhdXRvdXBkYXRlLgouLi9saWIvYXV0b2NvbmYvZ2VuZXJhbC5tNDoyMDQ6IEFDX0hFTFBf U1RSSU5HIGlzIGV4cGFuZGVkIGZyb20uLi4Kc250cC9saWJvcHRzL200L2xpYm9wdHMubTQ6NDc1 OiBMSUJPUFRTX0NIRUNLX0NPTU1PTiBpcyBleHBhbmRlZCBmcm9tLi4uCnNudHAvbGlib3B0cy9t NC9saWJvcHRzLm00OjU2NjogTElCT1BUU19DSEVDS19OT0JVSUxEIGlzIGV4cGFuZGVkIGZyb20u Li4KY29uZmlndXJlLmFjOjExNjogdGhlIHRvcCBsZXZlbApjb25maWd1cmUuYWM6MTE4OiB3YXJu aW5nOiBUaGUgbWFjcm8gJ0FDX0hFTFBfU1RSSU5HJyBpcyBvYnNvbGV0ZS4KY29uZmlndXJlLmFj OjExODogWW91IHNob3VsZCBydW4gYXV0b3VwZGF0ZS4KLi4vbGliL2F1dG9jb25mL2dlbmVyYWwu bTQ6MjA0OiBBQ19IRUxQX1NUUklORyBpcyBleHBhbmRlZCBmcm9tLi4uCi4uL2xpYi9hdXRvY29u Zi9nZW5lcmFsLm00OjE1MzQ6IEFDX0FSR19FTkFCTEUgaXMgZXhwYW5kZWQgZnJvbS4uLgpzbnRw L200L250cF9saWJldmVudC5tNDozMTogTlRQX0VOQUJMRV9MT0NBTF9MSUJFVkVOVCBpcyBleHBh bmRlZCBmcm9tLi4uCnNudHAvbTQvbnRwX2xpYmV2ZW50Lm00OjYwOiBOVFBfTElCRVZFTlRfQ0hF Q0tfTk9CVUlMRCBpcyBleHBhbmRlZCBmcm9tLi4uCmNvbmZpZ3VyZS5hYzoxMTg6IHRoZSB0b3Ag bGV2ZWwKY29uZmlndXJlLmFjOjEyMDogd2FybmluZzogVGhlIG1hY3JvICdBQ19UUllfTElOSycg aXMgb2Jzb2xldGUuCmNvbmZpZ3VyZS5hYzoxMjA6IFlvdSBzaG91bGQgcnVuIGF1dG91cGRhdGUu Ci4uL2xpYi9hdXRvY29uZi9nZW5lcmFsLm00OjI5MTg6IEFDX1RSWV9MSU5LIGlzIGV4cGFuZGVk IGZyb20uLi4KLi4vbGliL200c3VnYXIvbTRzaC5tNDo2OTc6IEFTX0lGIGlzIGV4cGFuZGVkIGZy b20uLi4KLi4vbGliL2F1dG9jb25mL2dlbmVyYWwubTQ6Mjk3OTogQUNfUlVOX0lGRUxTRSBpcyBl eHBhbmRlZCBmcm9tLi4uCi4uL2xpYi9tNHN1Z2FyL200c2gubTQ6NjkwOiBfQVNfSUZfRUxTRSBp cyBleHBhbmRlZCBmcm9tLi4uCi4uL2xpYi9tNHN1Z2FyL200c2gubTQ6Njk3OiBBU19JRiBpcyBl eHBhbmRlZCBmcm9tLi4uCi4uL2xpYi9hdXRvY29uZi9nZW5lcmFsLm00OjIyNDk6IEFDX0NBQ0hF X1ZBTCBpcyBleHBhbmRlZCBmcm9tLi4uCi4uL2xpYi9hdXRvY29uZi9nZW5lcmFsLm00OjIyNzA6 IEFDX0NBQ0hFX0NIRUNLIGlzIGV4cGFuZGVkIGZyb20uLi4Kc250cC9tNC9vcGVubGRhcC10aHJl YWQtY2hlY2subTQ6MjM6IE9MX1RIUkVBRF9DSEVDSyBpcyBleHBhbmRlZCBmcm9tLi4uCnNudHAv bTQvbnRwX2xpYm50cC5tNDo5OiBOVFBfTElCTlRQIGlzIGV4cGFuZGVkIGZyb20uLi4KY29uZmln dXJlLmFjOjEyMDogdGhlIHRvcCBsZXZlbApjb25maWd1cmUuYWM6MjE5OiB3YXJuaW5nOiBUaGUg bWFjcm8gJ0FDX1RSWV9SVU4nIGlzIG9ic29sZXRlLgpjb25maWd1cmUuYWM6MjE5OiBZb3Ugc2hv dWxkIHJ1biBhdXRvdXBkYXRlLgouLi9saWIvYXV0b2NvbmYvZ2VuZXJhbC5tNDoyOTk1OiBBQ19U UllfUlVOIGlzIGV4cGFuZGVkIGZyb20uLi4KY29uZmlndXJlLmFjOjIxOTogdGhlIHRvcCBsZXZl bApjb25maWd1cmUuYWM6NTI1OiB3YXJuaW5nOiBUaGUgbWFjcm8gJ0FDX1RZUEVfU0lHTkFMJyBp cyBvYnNvbGV0ZS4KY29uZmlndXJlLmFjOjUyNTogWW91IHNob3VsZCBydW4gYXV0b3VwZGF0ZS4K Li4vbGliL2F1dG9jb25mL3R5cGVzLm00OjgwNTogQUNfVFlQRV9TSUdOQUwgaXMgZXhwYW5kZWQg ZnJvbS4uLgpjb25maWd1cmUuYWM6NTI1OiB0aGUgdG9wIGxldmVsCmNvbmZpZ3VyZS5hYzoyOTc5 OiB3YXJuaW5nOiBUaGUgbWFjcm8gJ0FDX0hFTFBfU1RSSU5HJyBpcyBvYnNvbGV0ZS4KY29uZmln dXJlLmFjOjI5Nzk6IFlvdSBzaG91bGQgcnVuIGF1dG91cGRhdGUuCi4uL2xpYi9hdXRvY29uZi9n ZW5lcmFsLm00OjIwNDogQUNfSEVMUF9TVFJJTkcgaXMgZXhwYW5kZWQgZnJvbS4uLgpjb25maWd1 cmUuYWM6Mjk3OTogdGhlIHRvcCBsZXZlbAphdXRvcmVjb25mOiBydW5uaW5nOiAvdXNyL2xvY2Fs L2Jpbi9hdXRvaGVhZGVyCmF1dG9yZWNvbmY6IHJ1bm5pbmc6IGF1dG9tYWtlIC0tYWRkLW1pc3Np bmcgLS1jb3B5IC0tbm8tZm9yY2UKY29uZmlndXJlLmFjOiBpbnN0YWxsaW5nICdzbnRwL2xpYmV2 ZW50L2J1aWxkLWF1eC95bHdyYXAnCmF1dG9yZWNvbmY6IExlYXZpbmcgZGlyZWN0b3J5ICcuJwps czogaW52YWxpZCB0YWIgc2l6ZTogJy4vYWNsb2NhbC5tNCcK --000000000000533766061c0a8d88 Content-Type: application/octet-stream; name="bootstrap-am-1.16.92.log" Content-Disposition: attachment; filename="bootstrap-am-1.16.92.log" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_ly0dvn1i1 VG91Y2hpbmcgPCBzbnRwL3Rlc3RzL2NyeXB0by5jIHNudHAvdGVzdHMva2V5RmlsZS5jIHNudHAv dGVzdHMva29kRGF0YWJhc2UuYyBzbnRwL3Rlc3RzL2tvZEZpbGUuYyBzbnRwL3Rlc3RzL25hbWVy ZXNvbHV0aW9uLmMgc250cC90ZXN0cy9uZXR3b3JraW5nLmMgc250cC90ZXN0cy9wYWNrZXRIYW5k bGluZy5jIHNudHAvdGVzdHMvcGFja2V0UHJvY2Vzc2luZy5jIHNudHAvdGVzdHMvdC1sb2cuYyBz bnRwL3Rlc3RzL3V0aWxpdGllcy5jIHRlc3RzL2J1Zy0yODAzL2J1Zy0yODAzLmMgdGVzdHMvbGli bnRwL2FfbWQ1ZW5jcnlwdC5jIHRlc3RzL2xpYm50cC9hdG9pbnQuYyB0ZXN0cy9saWJudHAvYXRv dWludC5jIHRlc3RzL2xpYm50cC9hdXRoa2V5cy5jIHRlc3RzL2xpYm50cC9idWZ0dnRvdHMuYyB0 ZXN0cy9saWJudHAvY2FsZW5kYXIuYyB0ZXN0cy9saWJudHAvY2FsanVsaWFuLmMgdGVzdHMvbGli bnRwL2NhbHRvbnRwLmMgdGVzdHMvbGlibnRwL2NhbHllYXJzdGFydC5jIHRlc3RzL2xpYm50cC9j bG9ja3RpbWUuYyB0ZXN0cy9saWJudHAvZGVjb2RlbmV0bnVtLmMgdGVzdHMvbGlibnRwL2RpZ2Vz dHMuYyB0ZXN0cy9saWJudHAvaGV4dG9pbnQuYyB0ZXN0cy9saWJudHAvaGV4dG9sZnAuYyB0ZXN0 cy9saWJudHAvaHVtYW5kYXRlLmMgdGVzdHMvbGlibnRwL2xmcGZ1bmMuYyB0ZXN0cy9saWJudHAv bGZwdG9zdHIuYyB0ZXN0cy9saWJudHAvbW9kZXRvYS5jIHRlc3RzL2xpYm50cC9tc3lzbG9nLmMg dGVzdHMvbGlibnRwL25ldG9mLmMgdGVzdHMvbGlibnRwL251bXRvYS5jIHRlc3RzL2xpYm50cC9v Y3R0b2ludC5jIHRlc3RzL2xpYm50cC9wcmV0dHlkYXRlLmMgdGVzdHMvbGlibnRwL3JlYWxwYXRo LmMgdGVzdHMvbGlibnRwL3JlY3ZidWZmLmMgdGVzdHMvbGlibnRwL3JlZmlkc21lYXIuYyB0ZXN0 cy9saWJudHAvcmVmbnVtdG9hLmMgdGVzdHMvbGlibnRwL3NicHJpbnRmLmMgdGVzdHMvbGlibnRw L3NmcHRvc3RyLmMgdGVzdHMvbGlibnRwL3NvY2t0b2EuYyB0ZXN0cy9saWJudHAvc3NsX2luaXQu YyB0ZXN0cy9saWJudHAvc3RhdGVzdHIuYyB0ZXN0cy9saWJudHAvc3RydG9sZnAuYyB0ZXN0cy9s aWJudHAvdGltZXNwZWNvcHMuYyB0ZXN0cy9saWJudHAvdGltZXZhbG9wcy5jIHRlc3RzL2xpYm50 cC90c2FmZW1lbWNtcC5jIHRlc3RzL2xpYm50cC90c3RvdHYuYyB0ZXN0cy9saWJudHAvdHZ0b3Rz LmMgdGVzdHMvbGlibnRwL3VnbHlkYXRlLmMgdGVzdHMvbGlibnRwL3ZpNjRvcHMuYyB0ZXN0cy9s aWJudHAveW1kMnlkLmMgdGVzdHMvbnRwZC9sZWFwc2VjLmMgdGVzdHMvbnRwZC9udHBfcHJpb19x LmMgdGVzdHMvbnRwZC9udHBfcmVzdHJpY3QuYyB0ZXN0cy9udHBkL250cF91dGlsLmMgdGVzdHMv bnRwZC9yY19jbWRsZW5ndGguYyB0ZXN0cy9udHBkL3QtbnRwX3NjYW5uZXIuYyB0ZXN0cy9udHBk L3QtbnRwX3NpZ25kLmMgdGVzdHMvbnRwcS90LW50cHEuYyB0ZXN0cy9zYW5kYm94L2J1Zy0yODAz LmMgdGVzdHMvc2FuZGJveC9tb2RldG9hLmMgdGVzdHMvc2FuZGJveC91Z2x5ZGF0ZS5jIHRlc3Rz L3NhbmRib3gvdXQtMjgwMy5jIHRlc3RzL3NlYy0yODUzL3NlYy0yODUzLmM+ClRvdWNoaW5nIDwg c250cC90ZXN0cy9ydW4tY3J5cHRvLmMgc250cC90ZXN0cy9ydW4ta2V5RmlsZS5jIHNudHAvdGVz dHMvcnVuLWtvZERhdGFiYXNlLmMgc250cC90ZXN0cy9ydW4ta29kRmlsZS5jIHNudHAvdGVzdHMv cnVuLW5hbWVyZXNvbHV0aW9uLmMgc250cC90ZXN0cy9ydW4tbmV0d29ya2luZy5jIHNudHAvdGVz dHMvcnVuLXBhY2tldEhhbmRsaW5nLmMgc250cC90ZXN0cy9ydW4tcGFja2V0UHJvY2Vzc2luZy5j IHNudHAvdGVzdHMvcnVuLXQtbG9nLmMgc250cC90ZXN0cy9ydW4tdXRpbGl0aWVzLmMgdGVzdHMv YnVnLTI4MDMvcnVuLWJ1Zy0yODAzLmMgdGVzdHMvbGlibnRwL3J1bi1hX21kNWVuY3J5cHQuYyB0 ZXN0cy9saWJudHAvcnVuLWF0b2ludC5jIHRlc3RzL2xpYm50cC9ydW4tYXRvdWludC5jIHRlc3Rz L2xpYm50cC9ydW4tYXV0aGtleXMuYyB0ZXN0cy9saWJudHAvcnVuLWJ1ZnR2dG90cy5jIHRlc3Rz L2xpYm50cC9ydW4tY2FsZW5kYXIuYyB0ZXN0cy9saWJudHAvcnVuLWNhbGp1bGlhbi5jIHRlc3Rz L2xpYm50cC9ydW4tY2FsdG9udHAuYyB0ZXN0cy9saWJudHAvcnVuLWNhbHllYXJzdGFydC5jIHRl c3RzL2xpYm50cC9ydW4tY2xvY2t0aW1lLmMgdGVzdHMvbGlibnRwL3J1bi1kZWNvZGVuZXRudW0u YyB0ZXN0cy9saWJudHAvcnVuLWRpZ2VzdHMuYyB0ZXN0cy9saWJudHAvcnVuLWhleHRvaW50LmMg dGVzdHMvbGlibnRwL3J1bi1oZXh0b2xmcC5jIHRlc3RzL2xpYm50cC9ydW4taHVtYW5kYXRlLmMg dGVzdHMvbGlibnRwL3J1bi1sZnBmdW5jLmMgdGVzdHMvbGlibnRwL3J1bi1sZnB0b3N0ci5jIHRl c3RzL2xpYm50cC9ydW4tbW9kZXRvYS5jIHRlc3RzL2xpYm50cC9ydW4tbXN5c2xvZy5jIHRlc3Rz L2xpYm50cC9ydW4tbmV0b2YuYyB0ZXN0cy9saWJudHAvcnVuLW51bXRvYS5jIHRlc3RzL2xpYm50 cC9ydW4tb2N0dG9pbnQuYyB0ZXN0cy9saWJudHAvcnVuLXByZXR0eWRhdGUuYyB0ZXN0cy9saWJu dHAvcnVuLXJlYWxwYXRoLmMgdGVzdHMvbGlibnRwL3J1bi1yZWN2YnVmZi5jIHRlc3RzL2xpYm50 cC9ydW4tcmVmaWRzbWVhci5jIHRlc3RzL2xpYm50cC9ydW4tcmVmbnVtdG9hLmMgdGVzdHMvbGli bnRwL3J1bi1zYnByaW50Zi5jIHRlc3RzL2xpYm50cC9ydW4tc2ZwdG9zdHIuYyB0ZXN0cy9saWJu dHAvcnVuLXNvY2t0b2EuYyB0ZXN0cy9saWJudHAvcnVuLXNzbF9pbml0LmMgdGVzdHMvbGlibnRw L3J1bi1zdGF0ZXN0ci5jIHRlc3RzL2xpYm50cC9ydW4tc3RydG9sZnAuYyB0ZXN0cy9saWJudHAv cnVuLXRpbWVzcGVjb3BzLmMgdGVzdHMvbGlibnRwL3J1bi10aW1ldmFsb3BzLmMgdGVzdHMvbGli bnRwL3J1bi10c2FmZW1lbWNtcC5jIHRlc3RzL2xpYm50cC9ydW4tdHN0b3R2LmMgdGVzdHMvbGli bnRwL3J1bi10dnRvdHMuYyB0ZXN0cy9saWJudHAvcnVuLXVnbHlkYXRlLmMgdGVzdHMvbGlibnRw L3J1bi12aTY0b3BzLmMgdGVzdHMvbGlibnRwL3J1bi15bWQyeWQuYyB0ZXN0cy9udHBkL3J1bi1s ZWFwc2VjLmMgdGVzdHMvbnRwZC9ydW4tbnRwX3ByaW9fcS5jIHRlc3RzL250cGQvcnVuLW50cF9y ZXN0cmljdC5jIHRlc3RzL250cGQvcnVuLW50cF91dGlsLmMgdGVzdHMvbnRwZC9ydW4tcmNfY21k bGVuZ3RoLmMgdGVzdHMvbnRwZC9ydW4tdC1udHBfc2Nhbm5lci5jIHRlc3RzL250cGQvcnVuLXQt bnRwX3NpZ25kLmMgdGVzdHMvbnRwcS9ydW4tdC1udHBxLmMgdGVzdHMvc2FuZGJveC9ydW4tYnVn LTI4MDMuYyB0ZXN0cy9zYW5kYm94L3J1bi1tb2RldG9hLmMgdGVzdHMvc2FuZGJveC9ydW4tdWds eWRhdGUuYyB0ZXN0cy9zYW5kYm94L3J1bi11dC0yODAzLmMgdGVzdHMvc2VjLTI4NTMvcnVuLXNl Yy0yODUzLmM+ClRvdWNoaW5nIDwgbnRwZC9udHAuY29uZi41bWFuIG50cGQvbnRwLmNvbmYuNW1k b2MgbnRwZC9udHAuY29uZi5tYW4uaW4gbnRwZC9udHAuY29uZi5tZG9jLmluIG50cGQvbnRwLmNv bmYudGV4aSBudHBkL250cC5rZXlzLjVtYW4gbnRwZC9udHAua2V5cy41bWRvYyBudHBkL250cC5r ZXlzLm1hbi5pbiBudHBkL250cC5rZXlzLm1kb2MuaW4gbnRwZC9udHAua2V5cy50ZXhpIG50cGQv bnRwZC1vcHRzLmMgbnRwZC9udHBkLW9wdHMuaCBudHBkL250cGQuMW50cGRtYW4gbnRwZC9udHBk LjFudHBkbWRvYyBudHBkL250cGQuYyBudHBkL250cGQubWFuLmluIG50cGQvbnRwZC5tZG9jLmlu IG50cGQvbnRwZC50ZXhpIG50cGQvbnRwZHNpbS1vcHRzLmMgbnRwZC9udHBkc2ltLW9wdHMuaCBu dHBkL250cGRzaW0tb3B0cy5tZW51IG50cGQvbnRwZHNpbS1vcHRzLnRleGkgbnRwZC9udHBkc2lt LW9wdHMuYyBudHBkL250cGRzaW0tb3B0cy5oIG50cGQvbnRwZHNpbS1vcHRzLm1lbnUgbnRwZC9u dHBkc2ltLW9wdHMudGV4aSBudHBkYy9udHBkYy1sYXlvdXQuYyBudHBkYy9udHBkYy1vcHRzLmMg bnRwZGMvbnRwZGMtb3B0cy5oIG50cGRjL250cGRjLjFudHBkY21hbiBudHBkYy9udHBkYy4xbnRw ZGNtZG9jIG50cGRjL250cGRjLmMgbnRwZGMvbnRwZGMuaCBudHBkYy9udHBkYy5tYW4uaW4gbnRw ZGMvbnRwZGMubWRvYy5pbiBudHBkYy9udHBkYy50ZXhpIG50cGRjL250cGRjX29wcy5jIG50cHEv bnRwcS1vcHRzLmMgbnRwcS9udHBxLW9wdHMuaCBudHBxL250cHEtc3Vicy5jIG50cHEvbnRwcS4x bnRwcW1hbiBudHBxL250cHEuMW50cHFtZG9jIG50cHEvbnRwcS5jIG50cHEvbnRwcS5oIG50cHEv bnRwcS5tYW4uaW4gbnRwcS9udHBxLm1kb2MuaW4gbnRwcS9udHBxLnRleGkgbnRwc25tcGQvbnRw c25tcGQtb3B0cy5jIG50cHNubXBkL250cHNubXBkLW9wdHMuaCBudHBzbm1wZC9udHBzbm1wZC4x bnRwc25tcGRtYW4gbnRwc25tcGQvbnRwc25tcGQuMW50cHNubXBkbWRvYyBudHBzbm1wZC9udHBz bm1wZC5jIG50cHNubXBkL250cHNubXBkLm1hbi5pbiBudHBzbm1wZC9udHBzbm1wZC5tZG9jLmlu IG50cHNubXBkL250cHNubXBkLnRleGkgc2NyaXB0cy9jYWxjX3RpY2thZGovY2FsY190aWNrYWRq LW9wdHMgc2NyaXB0cy9jYWxjX3RpY2thZGovY2FsY190aWNrYWRqLjFjYWxjX3RpY2thZGptYW4g c2NyaXB0cy9jYWxjX3RpY2thZGovY2FsY190aWNrYWRqLjFjYWxjX3RpY2thZGptZG9jIHNjcmlw dHMvY2FsY190aWNrYWRqL2NhbGNfdGlja2Fkai5tYW4uaW4gc2NyaXB0cy9jYWxjX3RpY2thZGov Y2FsY190aWNrYWRqLm1kb2MuaW4gc2NyaXB0cy9jYWxjX3RpY2thZGovY2FsY190aWNrYWRqLnRl eGkgc2NyaXB0cy9udHAtd2FpdC9udHAtd2FpdC1vcHRzIHNjcmlwdHMvbnRwLXdhaXQvbnRwLXdh aXQuMW50cC13YWl0bWFuIHNjcmlwdHMvbnRwLXdhaXQvbnRwLXdhaXQuMW50cC13YWl0bWRvYyBz Y3JpcHRzL250cC13YWl0L250cC13YWl0Lm1hbi5pbiBzY3JpcHRzL250cC13YWl0L250cC13YWl0 Lm1kb2MuaW4gc2NyaXB0cy9udHAtd2FpdC9udHAtd2FpdC50ZXhpIHNjcmlwdHMvbnRwc3dlZXAv bnRwc3dlZXAtb3B0cyBzY3JpcHRzL250cHN3ZWVwL250cHN3ZWVwLjFudHBzd2VlcG1hbiBzY3Jp cHRzL250cHN3ZWVwL250cHN3ZWVwLjFudHBzd2VlcG1kb2Mgc2NyaXB0cy9udHBzd2VlcC9udHBz d2VlcC5tYW4uaW4gc2NyaXB0cy9udHBzd2VlcC9udHBzd2VlcC5tZG9jLmluIHNjcmlwdHMvbnRw c3dlZXAvbnRwc3dlZXAudGV4aSBzY3JpcHRzL250cHRyYWNlL250cHRyYWNlLW9wdHMgc2NyaXB0 cy9udHB0cmFjZS9udHB0cmFjZS4xbnRwdHJhY2VtYW4gc2NyaXB0cy9udHB0cmFjZS9udHB0cmFj ZS4xbnRwdHJhY2VtZG9jIHNjcmlwdHMvbnRwdHJhY2UvbnRwdHJhY2UubWFuLmluIHNjcmlwdHMv bnRwdHJhY2UvbnRwdHJhY2UubWRvYy5pbiBzY3JpcHRzL250cHRyYWNlL250cHRyYWNlLnRleGkg c2NyaXB0cy9wbG90X3N1bW1hcnktb3B0cyBzY3JpcHRzL3Bsb3Rfc3VtbWFyeS4xcGxvdF9zdW1t YXJ5bWFuIHNjcmlwdHMvcGxvdF9zdW1tYXJ5LjFwbG90X3N1bW1hcnltZG9jIHNjcmlwdHMvcGxv dF9zdW1tYXJ5Lm1hbi5pbiBzY3JpcHRzL3Bsb3Rfc3VtbWFyeS5tZG9jLmluIHNjcmlwdHMvcGxv dF9zdW1tYXJ5LnRleGkgc2NyaXB0cy9zdW1tYXJ5LW9wdHMgc2NyaXB0cy9zdW1tYXJ5LjFzdW1t YXJ5bWFuIHNjcmlwdHMvc3VtbWFyeS4xc3VtbWFyeW1kb2Mgc2NyaXB0cy9zdW1tYXJ5Lm1hbi5p biBzY3JpcHRzL3N1bW1hcnkubWRvYy5pbiBzY3JpcHRzL3N1bW1hcnkudGV4aSBzY3JpcHRzL3Vw ZGF0ZS1sZWFwL3VwZGF0ZS1sZWFwLW9wdHMgc2NyaXB0cy91cGRhdGUtbGVhcC91cGRhdGUtbGVh cC4xdXBkYXRlLWxlYXBtYW4gc2NyaXB0cy91cGRhdGUtbGVhcC91cGRhdGUtbGVhcC4xdXBkYXRl LWxlYXBtZG9jIHNjcmlwdHMvdXBkYXRlLWxlYXAvdXBkYXRlLWxlYXAubWFuLmluIHNjcmlwdHMv dXBkYXRlLWxlYXAvdXBkYXRlLWxlYXAubWRvYy5pbiBzY3JpcHRzL3VwZGF0ZS1sZWFwL3VwZGF0 ZS1sZWFwLnRleGkgc250cC9zbnRwLW9wdHMuYyBzbnRwL3NudHAtb3B0cy5oIHNudHAvc250cC4x c250cG1hbiBzbnRwL3NudHAuMXNudHBtZG9jIHNudHAvc250cC5jIHNudHAvc250cC5tYW4uaW4g c250cC9zbnRwLm1kb2MuaW4gc250cC9zbnRwLnRleGkgdXRpbC9udHAta2V5Z2VuLW9wdHMuYyB1 dGlsL250cC1rZXlnZW4tb3B0cy5oIHV0aWwvbnRwLWtleWdlbi4xbnRwLWtleWdlbm1hbiB1dGls L250cC1rZXlnZW4uMW50cC1rZXlnZW5tZG9jIHV0aWwvbnRwLWtleWdlbi5jIHV0aWwvbnRwLWtl eWdlbi5tYW4uaW4gdXRpbC9udHAta2V5Z2VuLm1kb2MuaW4gdXRpbC9udHAta2V5Z2VuLnRleGk+ ClRvdWNoaW5nIDwgbnRwZC9pbnZva2UtbnRwLmNvbmYubWVudSBudHBkL2ludm9rZS1udHAuY29u Zi50ZXhpIG50cGQvaW52b2tlLW50cC5rZXlzLm1lbnUgbnRwZC9pbnZva2UtbnRwLmtleXMudGV4 aSBudHBkL2ludm9rZS1udHBkLm1lbnUgbnRwZC9pbnZva2UtbnRwZC50ZXhpIG50cGQvaW52b2tl LW50cC5jb25mLm1lbnUgbnRwZC9pbnZva2UtbnRwLmNvbmYudGV4aSBudHBkL2ludm9rZS1udHAu a2V5cy5tZW51IG50cGQvaW52b2tlLW50cC5rZXlzLnRleGkgbnRwZC9pbnZva2UtbnRwZC5tZW51 IG50cGQvaW52b2tlLW50cGQudGV4aSBudHBkL2ludm9rZS1udHAuY29uZi5tZW51IG50cGQvaW52 b2tlLW50cC5jb25mLnRleGkgbnRwZC9pbnZva2UtbnRwLmtleXMubWVudSBudHBkL2ludm9rZS1u dHAua2V5cy50ZXhpIG50cGQvaW52b2tlLW50cGQubWVudSBudHBkL2ludm9rZS1udHBkLnRleGkg bnRwZC9pbnZva2UtbnRwLmNvbmYubWVudSBudHBkL2ludm9rZS1udHAuY29uZi50ZXhpIG50cGQv aW52b2tlLW50cC5rZXlzLm1lbnUgbnRwZC9pbnZva2UtbnRwLmtleXMudGV4aSBudHBkL2ludm9r ZS1udHBkLm1lbnUgbnRwZC9pbnZva2UtbnRwZC50ZXhpIG50cGRjL2ludm9rZS1udHBkYy5tZW51 IG50cGRjL2ludm9rZS1udHBkYy50ZXhpIG50cHEvaW52b2tlLW50cHEubWVudSBudHBxL2ludm9r ZS1udHBxLnRleGkgbnRwc25tcGQvaW52b2tlLW50cHNubXBkLm1lbnUgbnRwc25tcGQvaW52b2tl LW50cHNubXBkLnRleGkgc2NyaXB0cy9jYWxjX3RpY2thZGovaW52b2tlLWNhbGNfdGlja2Fkai5t ZW51IHNjcmlwdHMvY2FsY190aWNrYWRqL2ludm9rZS1jYWxjX3RpY2thZGoudGV4aSBzY3JpcHRz L250cC13YWl0L2ludm9rZS1udHAtd2FpdC5tZW51IHNjcmlwdHMvbnRwLXdhaXQvaW52b2tlLW50 cC13YWl0LnRleGkgc2NyaXB0cy9udHBzd2VlcC9pbnZva2UtbnRwc3dlZXAubWVudSBzY3JpcHRz L250cHN3ZWVwL2ludm9rZS1udHBzd2VlcC50ZXhpIHNjcmlwdHMvbnRwdHJhY2UvaW52b2tlLW50 cHRyYWNlLm1lbnUgc2NyaXB0cy9udHB0cmFjZS9pbnZva2UtbnRwdHJhY2UudGV4aSBzY3JpcHRz L2ludm9rZS1wbG90X3N1bW1hcnkubWVudSBzY3JpcHRzL2ludm9rZS1wbG90X3N1bW1hcnkudGV4 aSBzY3JpcHRzL2ludm9rZS1zdW1tYXJ5Lm1lbnUgc2NyaXB0cy9pbnZva2Utc3VtbWFyeS50ZXhp IHNjcmlwdHMvaW52b2tlLXBsb3Rfc3VtbWFyeS5tZW51IHNjcmlwdHMvaW52b2tlLXBsb3Rfc3Vt bWFyeS50ZXhpIHNjcmlwdHMvaW52b2tlLXN1bW1hcnkubWVudSBzY3JpcHRzL2ludm9rZS1zdW1t YXJ5LnRleGkgc2NyaXB0cy91cGRhdGUtbGVhcC9pbnZva2UtdXBkYXRlLWxlYXAubWVudSBzY3Jp cHRzL3VwZGF0ZS1sZWFwL2ludm9rZS11cGRhdGUtbGVhcC50ZXhpIHNudHAvaW52b2tlLXNudHAu bWVudSBzbnRwL2ludm9rZS1zbnRwLnRleGkgdXRpbC9pbnZva2UtbnRwLWtleWdlbi5tZW51IHV0 aWwvaW52b2tlLW50cC1rZXlnZW4udGV4aT4KVG91Y2hpbmcgPCBudHBkL250cC5jb25mLmh0bWwg bnRwZC9udHAua2V5cy5odG1sIG50cGQvbnRwZC5odG1sIG50cGRjL250cGRjLmh0bWwgbnRwcS9u dHBxLmh0bWwgbnRwc25tcGQvbnRwc25tcGQuaHRtbCBzY3JpcHRzL2NhbGNfdGlja2Fkai9jYWxj X3RpY2thZGouaHRtbCBzY3JpcHRzL250cC13YWl0L250cC13YWl0Lmh0bWwgc2NyaXB0cy9udHBz d2VlcC9udHBzd2VlcC5odG1sIHNjcmlwdHMvbnRwdHJhY2UvbnRwdHJhY2UuaHRtbCBzY3JpcHRz L3Bsb3Rfc3VtbWFyeS5odG1sIHNjcmlwdHMvc3VtbWFyeS5odG1sIHNjcmlwdHMvdXBkYXRlLWxl YXAvdXBkYXRlLWxlYXAuaHRtbCBzbnRwL3NudHAuaHRtbCB1dGlsL250cC1rZXlnZW4uaHRtbD4K YXV0b3JlY29uZjogZXhwb3J0IFdBUk5JTkdTPQphdXRvcmVjb25mOiBFbnRlcmluZyBkaXJlY3Rv cnkgJy4nCmF1dG9yZWNvbmY6IGNvbmZpZ3VyZS5hYzogbm90IHVzaW5nIEdldHRleHQKYXV0b3Jl Y29uZjogcnVubmluZzogYWNsb2NhbCAtSSBzbnRwL200IC1JIHNudHAvbGliZXZlbnQvbTQgLUkg c250cC9saWJvcHRzL200CmF1dG9yZWNvbmY6IGNvbmZpZ3VyZS5hYzogdHJhY2luZwphdXRvcmVj b25mOiBjb25maWd1cmUuYWM6IGFkZGluZyBzdWJkaXJlY3Rvcnkgc250cCB0byBhdXRvcmVjb25m CmF1dG9yZWNvbmY6IEVudGVyaW5nIGRpcmVjdG9yeSAnc250cCcKYXV0b3JlY29uZjogY29uZmln dXJlLmFjOiBub3QgdXNpbmcgR2V0dGV4dAphdXRvcmVjb25mOiBydW5uaW5nOiBhY2xvY2FsIC1J IG00IC1JIGxpYmV2ZW50L200IC1JIGxpYm9wdHMvbTQKYXV0b3JlY29uZjogY29uZmlndXJlLmFj OiB0cmFjaW5nCmF1dG9yZWNvbmY6IGNvbmZpZ3VyZS5hYzogYWRkaW5nIHN1YmRpcmVjdG9yeSBs aWJldmVudCB0byBhdXRvcmVjb25mCmF1dG9yZWNvbmY6IEVudGVyaW5nIGRpcmVjdG9yeSAnbGli ZXZlbnQnCmF1dG9yZWNvbmY6IGNvbmZpZ3VyZS5hYzogbm90IHVzaW5nIEdldHRleHQKYXV0b3Jl Y29uZjogcnVubmluZzogYWNsb2NhbCAtSSBtNAphdXRvcmVjb25mOiBjb25maWd1cmUuYWM6IHRy YWNpbmcKYXV0b3JlY29uZjogY29uZmlndXJlLmFjOiBjcmVhdGluZyBkaXJlY3RvcnkgYnVpbGQt YXV4CmF1dG9yZWNvbmY6IGNvbmZpZ3VyZS5hYzogbm90IHVzaW5nIExpYnRvb2wKYXV0b3JlY29u ZjogY29uZmlndXJlLmFjOiBub3QgdXNpbmcgSW50bHRvb2wKYXV0b3JlY29uZjogY29uZmlndXJl LmFjOiBub3QgdXNpbmcgR3RrZG9jCmF1dG9yZWNvbmY6IHJ1bm5pbmc6IC91c3IvYmluL2F1dG9j b25mCmNvbmZpZ3VyZS5hYzozNTc6IHdhcm5pbmc6IFRoZSBtYWNybyBgQUNfSEVBREVSX1RJTUUn IGlzIG9ic29sZXRlLgpjb25maWd1cmUuYWM6MzU3OiBZb3Ugc2hvdWxkIHJ1biBhdXRvdXBkYXRl LgouL2xpYi9hdXRvY29uZi9oZWFkZXJzLm00Ojc0MzogQUNfSEVBREVSX1RJTUUgaXMgZXhwYW5k ZWQgZnJvbS4uLgpjb25maWd1cmUuYWM6MzU3OiB0aGUgdG9wIGxldmVsCmNvbmZpZ3VyZS5hYzo4 MDU6IHdhcm5pbmc6IFRoZSBtYWNybyBgQUNfVFJZX0xJTksnIGlzIG9ic29sZXRlLgpjb25maWd1 cmUuYWM6ODA1OiBZb3Ugc2hvdWxkIHJ1biBhdXRvdXBkYXRlLgouL2xpYi9hdXRvY29uZi9nZW5l cmFsLm00OjI5MjA6IEFDX1RSWV9MSU5LIGlzIGV4cGFuZGVkIGZyb20uLi4KbTQvYWN4X3B0aHJl YWQubTQ6ODY6IEFDWF9QVEhSRUFEIGlzIGV4cGFuZGVkIGZyb20uLi4KY29uZmlndXJlLmFjOjgw NTogdGhlIHRvcCBsZXZlbApjb25maWd1cmUuYWM6MTAxMjogd2FybmluZzogQUNfT1VUUFVUIHNo b3VsZCBiZSB1c2VkIHdpdGhvdXQgYXJndW1lbnRzLgpjb25maWd1cmUuYWM6MTAxMjogWW91IHNo b3VsZCBydW4gYXV0b3VwZGF0ZS4KYXV0b3JlY29uZjogcnVubmluZzogL3Vzci9iaW4vYXV0b2hl YWRlcgphdXRvcmVjb25mOiBydW5uaW5nOiBhdXRvbWFrZSAtLWFkZC1taXNzaW5nIC0tY29weSAt LW5vLWZvcmNlCmNvbmZpZ3VyZS5hYzoyNDogaW5zdGFsbGluZyAnYnVpbGQtYXV4L2NvbXBpbGUn CmNvbmZpZ3VyZS5hYzoyNjogaW5zdGFsbGluZyAnYnVpbGQtYXV4L2NvbmZpZy5ndWVzcycKY29u ZmlndXJlLmFjOjI2OiBpbnN0YWxsaW5nICdidWlsZC1hdXgvY29uZmlnLnN1YicKY29uZmlndXJl LmFjOjE0OiBpbnN0YWxsaW5nICdidWlsZC1hdXgvaW5zdGFsbC1zaCcKY29uZmlndXJlLmFjOjE0 OiBpbnN0YWxsaW5nICdidWlsZC1hdXgvbWlzc2luZycKTWFrZWZpbGUuYW06MTYxOiBlcnJvcjog TGlidG9vbCBsaWJyYXJ5IHVzZWQgYnV0ICdMSUJUT09MJyBpcyB1bmRlZmluZWQKTWFrZWZpbGUu YW06MTYxOiAgIFRoZSB1c3VhbCB3YXkgdG8gZGVmaW5lICdMSUJUT09MJyBpcyB0byBhZGQgJ0xU X0lOSVQnCk1ha2VmaWxlLmFtOjE2MTogICB0byAnY29uZmlndXJlLmFjJyBhbmQgcnVuICdhY2xv Y2FsJyBhbmQgJ2F1dG9jb25mJyBhZ2Fpbi4KTWFrZWZpbGUuYW06MTYxOiAgIElmICdMVF9JTklU JyBpcyBpbiAnY29uZmlndXJlLmFjJywgbWFrZSBzdXJlCk1ha2VmaWxlLmFtOjE2MTogICBpdHMg ZGVmaW5pdGlvbiBpcyBpbiBhY2xvY2FsJ3Mgc2VhcmNoIHBhdGguCk1ha2VmaWxlLmFtOiBpbnN0 YWxsaW5nICdidWlsZC1hdXgvZGVwY29tcCcKcGFyYWxsZWwtdGVzdHM6IGluc3RhbGxpbmcgJ2J1 aWxkLWF1eC90ZXN0LWRyaXZlcicKYXV0b3JlY29uZjogZXJyb3I6IGF1dG9tYWtlIGZhaWxlZCB3 aXRoIGV4aXQgc3RhdHVzOiAxCg== --000000000000533766061c0a8d88-- From debbugs-submit-bounces@debbugs.gnu.org Sun Jun 30 13:30:07 2024 Received: (at 71847) by debbugs.gnu.org; 30 Jun 2024 17:30:07 +0000 Received: from localhost ([127.0.0.1]:58958 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sNyNL-0005My-4H for submit@debbugs.gnu.org; Sun, 30 Jun 2024 13:30:07 -0400 Received: from mail-yb1-f176.google.com ([209.85.219.176]:47249) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sNyNJ-0005Lx-9r for 71847@debbugs.gnu.org; Sun, 30 Jun 2024 13:30:05 -0400 Received: by mail-yb1-f176.google.com with SMTP id 3f1490d57ef6-e02c4983bfaso2135992276.2 for <71847@debbugs.gnu.org>; Sun, 30 Jun 2024 10:30:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1719768539; x=1720373339; darn=debbugs.gnu.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=IZ97vlVN7RTMbumm4NESv/W4eLoZ7TXIRhhFA6Vcz2c=; b=cVa8OhElNS2bhLBmvxIFvWsBkc/vf/f7l4Wy31w9oc4T0ADFd12wwrlqojtTE9xVdl roUWQN2ZE6rKqHmXZn6gpaTPqhc7XLI9kO0hZKuXLBdcdI5QwMvc9ksXvDqlYUw1UMdB kJBIik9q6z0nFiZVhTxBHbD+yfVL5AgLN60vXra01zHwnB/AwDufGJHQuMJFnBFk18Lz QtO2igE/cuvaPGsziZEiVH7/c4LCpIuvCBgfle5wKQx19WWwNFBsS33LsSaDRZHAxNxs ZfJ3i2ejMA4kZOPSPqt68UjEEYJrp2WD8VV50WHy6GNO94e3LOyB7L1kMl3Vn51lGhRB fU2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1719768539; x=1720373339; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=IZ97vlVN7RTMbumm4NESv/W4eLoZ7TXIRhhFA6Vcz2c=; b=RgABajaM/0FBMUK6s63S8R73TIW0N1r9LgZCwmsp88AlvVSE1F0iaG9Y/EA1gOcajo YflMdkneOI8BnzSaQo6PSIArwtHu1jZBBAAncr0Hf67XkpXW6me8EjRV0BxNGh0S7+Pw M3SqZxva/SHzAj9XFG2a3DPNAZXngTQW7Cl4XM1ACDiuEkdQon4mMMWKalAg0oXwqM9e nyvCven6VfoMApx6q2d5X/Fc4wASW9QWk5v9CBZQV4JlkNAMTaFd86xNNZC1FLmD3j79 p8xq6OOUPXw4PpfGUjSsYuS/eiRytnkjaSaOiCkrKQfnE0FapEQE55HCNrTTdRa4w9Qw o/1g== X-Gm-Message-State: AOJu0YymNwuAdYlwgEenMsyTlWMiEXrM6VSOBuVJyl1vpOrRgeKPYf0n kuP74Kx+cz+r8OpVZhRwqTw2mXx93R7WGnWdDiG2hVzh0YmXYFtg+x/Ltw06I1tpVN+9CN3UDjJ i2Ua/Y6DD5VSQL852/aOkxKIKpbCCAUAw X-Google-Smtp-Source: AGHT+IHAnxFMOWrop1lJMj0I/ozYycWkbVg47s6AAJbLIt7xudhtVpdaDSV0CySMSU3DcRfJLtG30PiHgTepEWjn+jM= X-Received: by 2002:a25:eb02:0:b0:e03:3d0a:bb14 with SMTP id 3f1490d57ef6-e036eb01b8dmr3584064276.11.1719768539256; Sun, 30 Jun 2024 10:28:59 -0700 (PDT) MIME-Version: 1.0 From: Dave Hart Date: Sun, 30 Jun 2024 17:28:48 +0000 Message-ID: Subject: Self-inflicted problem, libtool and automake installed to different prefixes To: 71847@debbugs.gnu.org Content-Type: multipart/alternative; boundary="000000000000e0e054061c1ed047" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 71847 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --000000000000e0e054061c1ed047 Content-Type: text/plain; charset="UTF-8" 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 and installing the prerelease version to a prefix earlier on my $PATH, not realizing I also needed to install libtool to the same prefix or take other steps to help aclocal find the libtool macro definitions. After installing libtool to the same prefix, the problem disappeared. --000000000000e0e054061c1ed047 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Nick Bowler helped educate me on aclocal a= nd libtool interaction on the Automake mailing list.=C2=A0 The reason I was= hitting this problem was aclocal was not finding libtool installed to the = same prefix as automake.=C2=A0 To test the prerelease automake I was leavin= g the base version of automake installed and installing the prerelease vers= ion to a prefix earlier on my $PATH, not realizing I also needed to install= libtool to the same prefix or take other steps to help aclocal find the li= btool macro definitions.=C2=A0 After installing libtool to the same prefix,= the problem disappeared.

--000000000000e0e054061c1ed047-- From debbugs-submit-bounces@debbugs.gnu.org Sun Jun 30 16:31:03 2024 Received: (at 71847) by debbugs.gnu.org; 30 Jun 2024 20:31:03 +0000 Received: from localhost ([127.0.0.1]:59235 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sO1CR-0004bb-FR for submit@debbugs.gnu.org; Sun, 30 Jun 2024 16:31:03 -0400 Received: from frenzy.freefriends.org ([198.99.81.75]:48310 helo=freefriends.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sO1CP-0004bC-Pc for 71847@debbugs.gnu.org; Sun, 30 Jun 2024 16:31:02 -0400 X-Envelope-From: karl@freefriends.org Received: from freefriends.org (localhost [127.0.0.1]) by freefriends.org (8.16.1/8.16.1) with ESMTPS id 45UKUs4p712486 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Sun, 30 Jun 2024 14:30:54 -0600 Received: (from apache@localhost) by freefriends.org (8.16.1/8.14.7/Submit) id 45UKUs4A712485; Sun, 30 Jun 2024 14:30:54 -0600 Date: Sun, 30 Jun 2024 14:30:54 -0600 Message-Id: <202406302030.45UKUs4A712485@freefriends.org> From: Karl Berry To: davehart@gmail.com Subject: Re: bug#71847: Self-inflicted problem, libtool and automake installed to different prefixes In-Reply-To: X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 71847 Cc: 71847@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) 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 anything to install libtool in the same test prefix early in PATH, and I've never had the problem. Unless libtool is not installed anywhere in PATH in your scenario. Then it makes sense :). --thanks, karl. From debbugs-submit-bounces@debbugs.gnu.org Sun Jun 30 16:42:38 2024 Received: (at control) by debbugs.gnu.org; 30 Jun 2024 20:42:38 +0000 Received: from localhost ([127.0.0.1]:59271 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sO1Ne-0004tq-0C for submit@debbugs.gnu.org; Sun, 30 Jun 2024 16:42:38 -0400 Received: from mail-yb1-f179.google.com ([209.85.219.179]:60908) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sO1Nc-0004tZ-6D for control@debbugs.gnu.org; Sun, 30 Jun 2024 16:42:36 -0400 Received: by mail-yb1-f179.google.com with SMTP id 3f1490d57ef6-e0356299630so1872106276.1 for ; Sun, 30 Jun 2024 13:42:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1719780090; x=1720384890; darn=debbugs.gnu.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=rSQZtevImgsPO/azvBDoeTyC/ga5ukNaKTitoKuLLG0=; b=TcGM1l2g0+MdJiSS3qOLn0RcljkXh/R6OXsFsgqrYt9as0zW7HPeJRrZW5Rye7oxGE LfSTCpF9wxUeW7Ay2tVf+4QO/a3x9GUpr3kPSL0ZVWsMa0wDkNY7MtA9aRQR4UUxaXJM Dh7oXA9KcgkzbfPKqLN9TpFzgXQMWfPmLcU5iUFR7WHWUYxJsudHQ8LCL3phF/ozx8wU gxXgq6Bg2Dm5paIUKdvjIYjtZOA6HlGc9HikGfxqFajApJ6tAbvbfQ093ERLDdaAo61i 4VP1vRm9iPLgNpBetiVXkao8GPWiOfhYe/JrFszTBficGujP5spVTE5V15L8MLhXBXND OlDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1719780090; x=1720384890; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=rSQZtevImgsPO/azvBDoeTyC/ga5ukNaKTitoKuLLG0=; b=NvsawN94Xc4Zyxc36m5+nOTlBrWPSHs4NQa4CH6h6YkwWm1hgYd4pgHGoIg5W0cZxN r9hNgPlGGOGgxGqf0j+JtybT9n96neKShcm+Gyb2OK2H1ClulZe1qlrtqyqkZkk5AgdS wnDoKtzdio1AnZfWL1b/GzCFAmiUqfgMOIq9HCFZZJG/exJ7nO6V0yXjw/6w/Kb289Ox 5PRgSP8QLIFd3+3b1eesgxiffGg3xMT2TBp6Tf41fVOiPgLkIEDqukEk6zrWTttauCig DMn5kBuBX+ZvCjU6a6H7RPzO3NzPEsNlXudZQsilD2jAs6ItdutLWJ9AoVRptTU4tyYQ G34A== X-Gm-Message-State: AOJu0YwZ6o1ULpO5JFNmpn8CHHWA7zQqxKwMLtWDsjlLgQ5YU8BGyfbf J7McV1O3WJExvS/ed+Je6c5AxqQ2DALPhiuYU/NkpmKalyL96XzdVkZF+aFIBmBOjEHdogPs7CB UuR2+YOx1CQcVZa1XkZVle5A+dCiWpgfpO/o= X-Google-Smtp-Source: AGHT+IEDV4KS2FHQthfhsLnRy9GvkbcidMtpO+lBvwxBt+GpqCUBxuy/7UBMG5hbB4HURcCUmwQ85i1sqAIJdn9xYm8= X-Received: by 2002:a25:db10:0:b0:df7:8dca:1ef2 with SMTP id 3f1490d57ef6-e036eb76bf2mr3730663276.34.1719780090217; Sun, 30 Jun 2024 13:41:30 -0700 (PDT) MIME-Version: 1.0 From: Dave Hart Date: Sun, 30 Jun 2024 20:41:19 +0000 Message-ID: Subject: To: control@debbugs.gnu.org Content-Type: multipart/alternative; boundary="0000000000005e8c4e061c218199" X-Spam-Score: 2.0 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: tags 71847 + notabug thanks tags 71847 + notabug thanks Content analysis details: (2.0 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 SPF_PASS SPF: sender matches SPF record 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (davehart[at]gmail.com) 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 0.0 HTML_MESSAGE BODY: HTML included in message -0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2) [209.85.219.179 listed in wl.mailspike.net] -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/, no trust [209.85.219.179 listed in list.dnswl.org] 2.0 BLANK_SUBJECT Subject is present but empty X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) --0000000000005e8c4e061c218199 Content-Type: text/plain; charset="UTF-8" tags 71847 + notabug thanks --0000000000005e8c4e061c218199 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
tags 71847 + notabug
th= anks

--0000000000005e8c4e061c218199-- From debbugs-submit-bounces@debbugs.gnu.org Sun Jun 30 18:40:21 2024 Received: (at 71847-close) by debbugs.gnu.org; 30 Jun 2024 22:40:21 +0000 Received: from localhost ([127.0.0.1]:59364 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sO3DZ-0002OO-0X for submit@debbugs.gnu.org; Sun, 30 Jun 2024 18:40:21 -0400 Received: from mail-yb1-f172.google.com ([209.85.219.172]:50673) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sO3DX-0002OA-HT for 71847-close@debbugs.gnu.org; Sun, 30 Jun 2024 18:40:19 -0400 Received: by mail-yb1-f172.google.com with SMTP id 3f1490d57ef6-dfde5ae0aaeso2317285276.1 for <71847-close@debbugs.gnu.org>; Sun, 30 Jun 2024 15:40:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1719787153; x=1720391953; darn=debbugs.gnu.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=xCcUUQI628bhYAZso3vU0/zjQ+2YcnlQq18YzK9e5+Y=; b=YA4aEtp/k6o7Uq9sbPPCdCERnIYLP4WLuJ+cj6JATFxcqjWFDrWtekS5gKFyQQoM6K pSKtxujA/9vNq5cKOd6iCydehsndp3Y9JkmpH7/JygX3rfsyzzhhoh0dGDmeb0W/lpW9 T+wu+hc1LDIVTTpMHiXBCLsu8apdAM7P5qcVjBuS+snFRAnGyxoZHeVPgSdymcZ7/E2v tRveigCPhCY/SewgyYVJAozSxTyTKM2Qs8pNKByeFZ9kxog1fn2qqQ1ergT5ho/niu00 niT/WVfZZVsZGP5+p2lR45lQh28LSBc7vuSawyYT1/22/W/QcVh63EOlV5KZ1cRMTj7h p2rA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1719787153; x=1720391953; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=xCcUUQI628bhYAZso3vU0/zjQ+2YcnlQq18YzK9e5+Y=; b=tk2z0XKPhjq+/FIxeAxU4b+E2scNdSdQxlKo7DGYWe0wHhpLMj3G+XuVs5yygohIFX /WhtXzAI6D//hNsddVQ9llcIoM9OkRXvARy7MMW8Olk1wyRsB11ygxak7UWt0jUH9ItT ofoDgfOuvVTxC1C2nJtNVfft/T5RfQCWPkzW+YUj4heSUGEKYUl16n78bBIGNdbC7U8z cpBDDSPSQ0GdW14+a7oa8S/+foGLdyjMWP4ipfYR7zfXFjtZI5VYQyMHcWCK+1yq9fLf 3vLzJS+Fcx7qZDYRLY1ByP+UCyDTn9BWlD4uXm0KuSrRVrOfCM+GVzvOXjjSvDn80wbz +Apg== X-Gm-Message-State: AOJu0YyGBpZgkWJkbDs+Bdz7lZZL+n2D81cQ3chxWFWekIuZ2lZYbKxW eWQ4VgYxer3PxwNzIHfsNY0k58Od6RlMvkB5GoM5PdRPZkBpbr/LbX7gOXC0V6Udaz+BIXUA1V1 Y2TdmKfkUhh54p0jW0MdZECkt9qyWxFo0 X-Google-Smtp-Source: AGHT+IGrSA9FHFZGlzuxV6Tzg42Fqt5S3VO57WMVsOgmLglJbiDkYy6KuOh+lTqIvS8yjEs6tZtGa5rT7V0Csl7VWuc= X-Received: by 2002:a25:20d6:0:b0:e03:4f86:89ce with SMTP id 3f1490d57ef6-e036ec55aadmr4102377276.42.1719787153534; Sun, 30 Jun 2024 15:39:13 -0700 (PDT) MIME-Version: 1.0 From: Dave Hart Date: Sun, 30 Jun 2024 22:39:02 +0000 Message-ID: Subject: To: 71847-close@debbugs.gnu.org Content-Type: multipart/alternative; boundary="000000000000603795061c23262c" X-Spam-Score: 4.4 (++++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Content analysis details: (4.4 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2) [209.85.219.172 listed in wl.mailspike.net] -0.0 SPF_PASS SPF: sender matches SPF record 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (davehart[at]gmail.com) 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 0.0 HTML_MESSAGE BODY: HTML included in message 0.1 MIME_HTML_MOSTLY BODY: Multipart message mostly text/html MIME -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/, no trust [209.85.219.172 listed in list.dnswl.org] 2.3 EMPTY_MESSAGE Message appears to have no textual parts 2.0 BLANK_SUBJECT Subject is present but empty X-Debbugs-Envelope-To: 71847-close X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 3.4 (+++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Content analysis details: (3.4 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/, no trust [209.85.219.172 listed in list.dnswl.org] -0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2) [209.85.219.172 listed in wl.mailspike.net] -0.0 SPF_PASS SPF: sender matches SPF record 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (davehart[at]gmail.com) 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 0.0 HTML_MESSAGE BODY: HTML included in message 0.1 MIME_HTML_MOSTLY BODY: Multipart message mostly text/html MIME 2.3 EMPTY_MESSAGE Message appears to have no textual parts 2.0 BLANK_SUBJECT Subject is present but empty -1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list manager --000000000000603795061c23262c Content-Type: text/plain; charset="UTF-8" --000000000000603795061c23262c Content-Type: text/html; charset="UTF-8"

--000000000000603795061c23262c-- From debbugs-submit-bounces@debbugs.gnu.org Mon Jul 01 16:22:55 2024 Received: (at 71847) by debbugs.gnu.org; 1 Jul 2024 20:22:55 +0000 Received: from localhost ([127.0.0.1]:34777 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sONY7-0001fL-1p for submit@debbugs.gnu.org; Mon, 01 Jul 2024 16:22:55 -0400 Received: from mail-yb1-f169.google.com ([209.85.219.169]:52717) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sONY5-0001fE-HI for 71847@debbugs.gnu.org; Mon, 01 Jul 2024 16:22:54 -0400 Received: by mail-yb1-f169.google.com with SMTP id 3f1490d57ef6-e03424caf21so3243682276.1 for <71847@debbugs.gnu.org>; Mon, 01 Jul 2024 13:22:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1719865312; x=1720470112; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=WHJJ9XcT7OjLgVtwRjCMxcQ/dRWHll9YDOmmciuz/Hw=; b=mytydgV+fCs8zNR7sv/41BOpxQea/IZvZz/MqDldBXWPjTSmL1YzzIXoZkA/iYzZg6 3DMuuCzC3ViJh3+rxGdSba3HMW1ZGK8ZldC4SFgPQkLN5zF12V50W+B9QDlFYNuhRU2t rntWwdi7RKd+CVlYuWpdK8jfrgw7f5RTAtC0AwCxXN7ANkXQdhyhleZ0eUVSgAd9gPC0 wSFNaweKI3Rtm0WEc5PdD3Dswl6yp8pyR9jRGEc4nDgIQByxwW3nmp2D230wVbDAkLe3 sEYB0BZ5gknHyie/hbT3pQTcvU0nhi1o0mgXyMEkpRXtgYGvYrhzHfkeop1rQ9Zrawh0 uePA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1719865312; x=1720470112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=WHJJ9XcT7OjLgVtwRjCMxcQ/dRWHll9YDOmmciuz/Hw=; b=GSqBUiKAf82zQSNdehXMFBcNWkkZ1WqHwCrkSMFiRZmBR7f3YFk8xDD/qATgpaJdUp 70AvJRWF9mfHiC0WP9Sy/mm04h8EKCswTdYEOqIB60h4KJdYEciPidQ3a2K5HKWz+mjb 5C8AyBUwuWSasofqaVNG3tZhv5hpmG58akWvJiMsYGylGBTPOmNPzw7xHWV9NlCS7kUT LCQ1nL+pWGISXTeAt4jQ+edjIER0+hXj+zrc/5RuLdFO0PAd//ZAevjCYJamzW9dLQ/k bERxgJ60oxzj9PhWaGzq8kDJqjEfxoIg5HnQZ4vBt7/EfRSJI0luUQ6PdiF3Map/Sm3f tsDA== X-Gm-Message-State: AOJu0Yy+z2Z4XcZVruPnIIZudvHSn79JdVlqJ7TUU123+iborSpypERa w53tg+PJB3V9fhQaep1f5vlGs/WOwV6ZTKTlo4XnfA5PgFfjoMgMrsKzAS72bYWXAL0k73DuJrt 38b8it3bd256cNbVkAsUuqZyEmBW7Z/w9Z28= X-Google-Smtp-Source: AGHT+IGGVTHTyISeo/x20u9hpSefa47pSRdKP0U03SNWmvY0INzqFDxWuanPG28NfonAcoJu1s1lpPNSur/e42nbXqA= X-Received: by 2002:a5b:44:0:b0:e03:6287:7305 with SMTP id 3f1490d57ef6-e036ec958cdmr6624678276.61.1719865311932; Mon, 01 Jul 2024 13:21:51 -0700 (PDT) MIME-Version: 1.0 References: <202406302030.45UKUs4A712485@freefriends.org> In-Reply-To: <202406302030.45UKUs4A712485@freefriends.org> From: Dave Hart Date: Mon, 1 Jul 2024 20:21:40 +0000 Message-ID: Subject: Re: bug#71847: Self-inflicted problem, libtool and automake installed to different prefixes To: Karl Berry Content-Type: multipart/alternative; boundary="000000000000fabafc061c35585e" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 71847 Cc: 71847@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --000000000000fabafc061c35585e Content-Type: text/plain; charset="UTF-8" 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 rather > baffled. When I test an automake pretest, I don't do anything to install > libtool in the same test prefix early in PATH, and I've never had the > problem. > > Unless libtool is not installed anywhere in PATH in your scenario. Then > it makes sense :). --thanks, karl. > I just reproduced it on a third system and see the same issue. It's an ancient 32-bit SPARC Solaris 10 system with a bunch of not-quite-so-old GNU tools under /usr/local/gnu): hart@pogo> m4 --version | head -1 m4 (GNU M4) 1.4.16 hart@pogo> libtool --version | head -1 libtool (GNU libtool) 2.4.2 hart@pogo> autoconf --version | head -1 autoconf (GNU Autoconf) 2.71 hart@pogo> autoconf --version | head -1 autoconf (GNU Autoconf) 2.71 hart@pogo> /usr/local/gnu/bin/automake --version | head -1 automake (GNU automake) 1.16.5 hart@pogo> $HOME/usr/local/bin/automake --version | head -1 automake (GNU automake) 1.16.92 hart@pogo> Repro steps # wget https://davehart.net/ntp/test/ntp-4.2.8p18-vcs.tar.xz # tar xf *p18-vcs*xz # cd *vcs # ./bootstrap Works fine with 1.16.5 in /usr/local/gnu/bin, breaks with $HOME/usr/local/bin earlier on $PATH It might be something about the libevent configure.ac or Makefille.am, the source tree has projects nested three deep: configure.ac sntp/configure.ac sntp/libevent/configure.ac If you are willing to spend some time, I'm guessing you could reproduce the failure. Thanks for taking an interest. Cheers, Dave Hart --000000000000fabafc061c35585e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sun, 30 Jun 2024 at 20:31, K= arl Berry <karl@freefriends.org<= /a>> wrote:
Hi Dave,

=C2=A0 =C2=A0 installed and installing the prerelease version to a prefix e= arlier on my
=C2=A0 =C2=A0 $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 anything to instal= l
libtool in the same test prefix early in PATH, and I've never had the problem.

Unless libtool is not installed anywhere in PATH in your scenario. Then
it makes sense :). --thanks, karl.

I jus= t reproduced it on a third system and see the same issue.=C2=A0 It's an= ancient 32-bit SPARC Solaris 10 system with a bunch of not-quite-so-old GN= U tools under /usr/local/gnu):

<= div class=3D"gmail_default" style=3D"font-size:small">hart@pogo> m4 --version | head -1
m4 (GNU M4) 1.4.16
hart@pogo= > libtool --version | head -1
libtool (GNU libtool) 2.4.2
hart@pog= o> autoconf --version | head -1
autoconf (GNU Autoconf) 2.71
hart@= pogo> autoconf --version | head -1
autoconf (GNU Autoconf) 2.71
ha= rt@pogo> /usr/local/gnu/bin/automake --version | head -1
automake (GN= U automake) 1.16.5
hart@pogo> $HOME/usr/local/bin/automake --version = | head -1
automake (GNU automake) 1.16.92
hart@pogo>

Repro = steps

https://davehart.net/ntp/test/ntp-4.2.8p18-vcs.tar.xz
# tar xf *p18-vcs*xz
= # cd *vcs
# ./bootstrap

Works fine with 1.16.5= in /usr/local/gnu/bin, breaks with $HOME/usr/local/bin earlier on $PATH

It mig= ht be something about the libevent configur= e.ac or Makefille.am, the source tree has projects nested three deep:

configure.ac
configure.ac
sntp/libevent/configure.ac

If= you are willing to spend some time, I'm guessing you could reproduce t= he failure.=C2=A0 Thanks for taking an interest.

Cheers,
--000000000000fabafc061c35585e-- From debbugs-submit-bounces@debbugs.gnu.org Mon Jul 01 17:46:48 2024 Received: (at 71847) by debbugs.gnu.org; 1 Jul 2024 21:46:48 +0000 Received: from localhost ([127.0.0.1]:34940 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sOOrI-00042k-Cu for submit@debbugs.gnu.org; Mon, 01 Jul 2024 17:46:48 -0400 Received: from frenzy.freefriends.org ([198.99.81.75]:35446 helo=freefriends.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sOOrF-00042a-Sg for 71847@debbugs.gnu.org; Mon, 01 Jul 2024 17:46:47 -0400 X-Envelope-From: karl@freefriends.org Received: from freefriends.org (localhost [127.0.0.1]) by freefriends.org (8.16.1/8.16.1) with ESMTPS id 461Lkbop823912 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Mon, 1 Jul 2024 15:46:37 -0600 Received: (from apache@localhost) by freefriends.org (8.16.1/8.14.7/Submit) id 461Lkbih823911; Mon, 1 Jul 2024 15:46:37 -0600 Date: Mon, 1 Jul 2024 15:46:37 -0600 Message-Id: <202407012146.461Lkbih823911@freefriends.org> From: Karl Berry To: davehart@gmail.com Subject: Re: bug#71847: Self-inflicted problem, libtool and automake installed to different prefixes In-Reply-To: X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 71847 Cc: 71847@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) 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. From debbugs-submit-bounces@debbugs.gnu.org Tue Jul 02 13:15:35 2024 Received: (at 71847) by debbugs.gnu.org; 2 Jul 2024 17:15:35 +0000 Received: from localhost ([127.0.0.1]:37575 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sOh6M-0004Ru-Tz for submit@debbugs.gnu.org; Tue, 02 Jul 2024 13:15:35 -0400 Received: from frenzy.freefriends.org ([198.99.81.75]:56370 helo=freefriends.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sOh6K-0004Rk-R3 for 71847@debbugs.gnu.org; Tue, 02 Jul 2024 13:15:34 -0400 X-Envelope-From: karl@freefriends.org Received: from freefriends.org (localhost [127.0.0.1]) by freefriends.org (8.16.1/8.16.1) with ESMTPS id 462HFLQI917035 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Tue, 2 Jul 2024 11:15:21 -0600 Received: (from apache@localhost) by freefriends.org (8.16.1/8.14.7/Submit) id 462HFLqm917034; Tue, 2 Jul 2024 11:15:21 -0600 Date: Tue, 2 Jul 2024 11:15:21 -0600 Message-Id: <202407021715.462HFLqm917034@freefriends.org> From: Karl Berry To: davehart@gmail.com Subject: Re: bug#71847: Self-inflicted problem, libtool and automake installed to different prefixes In-Reply-To: X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 71847 Cc: 71847@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) 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 /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 . The behavior is the same with all the post-1.16.5 pretests, as far as I can see. Ok, I admit I didn't try the --system-acdir option with all versions, but it did work with both 1.16.5 and 1.16.92. For the record, I did install one change (mostly devised by Mike Frysinger, though I tweaked it, so any bugs are my responsibility) into aclocal in this regard that is only in 1.16.92 (and dev): https://lists.gnu.org/archive/html/automake-commit/2024-06/msg00019.html It adds a command-line option --aclocal-path and adjust the --help output to more accurately report the m4 search paths. That seemed suspicious at first, but per above, I no longer think it's a factor. (Unfortunately that list of search paths shown by aclocal --help is still far from optimal, since the implementation of all the different ways to set paths is rather convoluted and I did not feel like untangling it. If anyone feels like working on that, great. I left some comments in the source.) Anyway, to sum up, I think there is nothing to change on the automake side here? Let me know if you see different behavior. And thanks again for the report. Helps to get to the bottom (I hope) of such things. Happy syncing, Karl From debbugs-submit-bounces@debbugs.gnu.org Tue Jul 02 13:36:10 2024 Received: (at 71847) by debbugs.gnu.org; 2 Jul 2024 17:36:11 +0000 Received: from localhost ([127.0.0.1]:37620 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sOhQI-0004yz-BN for submit@debbugs.gnu.org; Tue, 02 Jul 2024 13:36:10 -0400 Received: from mail-yb1-f174.google.com ([209.85.219.174]:61499) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sOhQF-0004yj-Oq for 71847@debbugs.gnu.org; Tue, 02 Jul 2024 13:36:09 -0400 Received: by mail-yb1-f174.google.com with SMTP id 3f1490d57ef6-e03a581276eso447299276.2 for <71847@debbugs.gnu.org>; Tue, 02 Jul 2024 10:36:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1719941701; x=1720546501; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=eDUa2BuJsZwVwEvVk26yDTl/GBjzcceA2zHM4h7jPWA=; b=AGEKDLcSbxqmaczpymvwUvZbbwQFiaXbBKTPi7ZcdonJnjgo5f6LwRaxnQXIe+I/WN 5y1v0cHVKXlH2+gjaPxEdQ7blAyZsXCDEjYAxk2Vv+yLbs/+S+wSVTJ+DjjzRiwLhRJA 6awKDoM4kY86RuDUlmDzXRQJI0rSRgISFz7kQzMClT3upaaeyaoRhsR4v6qwBGaUpio6 voOb3Dfs9H/yuik9BYvl0r0T3TK2wro5VvRVyqNDJovgBnpEghL9HY9W0IQe3a5cA6fS SS6JU/+lj1yvlLhfwQiZBAlK7kVtpat4v8jr5AvIqMTJCKjK0jyeCi7eneX63geIt5M8 PgYA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1719941701; x=1720546501; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=eDUa2BuJsZwVwEvVk26yDTl/GBjzcceA2zHM4h7jPWA=; b=lr/+UBVdeaS/n9njSXAAFLzlP5xyg2uUV/2lGVDmFDLu0Ph6NuS87vKB6/scDlzwI4 RFOKqOVnVHwnNnpx0Ay/l8ezxTzRwFAYyr5oeytlRnac6Qs42s/Xtz0X8ReT2s2oPinA PshwCvFkoSWKskiP309naR0eK9d07l/5NoJfKgm+NtVZU8hN+35FOXrBSLkcUT0jjqeA G1OLAiPRg0kl+f7g3uG3Wro4qi/WgNQn+Bz0uDFXJ0drhvlaXkeghzVDHWqe/Guwq3bN d5NNvtAsCIL73aT3sd5CrYBaIWkAP/rnOXJDOTlDfFOZBPpRj0DqfSyZUgTfG6pDVrWg 5rDA== X-Gm-Message-State: AOJu0YxtERQ3iPQ1+5iQFFjJeYC34zN2d+xq1JA534Jz8LmArh4YDjFa gDp3AJSnIxk8s0hVHKzAje28GOK3x1q4PSxlQ0xCcPzth+jhHM/ylaF+tjBJwf1uLAWmzZvLvVM aBfVTTNiqGm13+fH3z5O1LJOSAes= X-Google-Smtp-Source: AGHT+IGlAu9PjEPLFIGGwAwEa9+snQ3GmBqBW/SNjsiYYOhHbdvxRzm9W77/RyFwuqMnn1MV6IHQroPKn6EEZyKYXlo= X-Received: by 2002:a25:bf8e:0:b0:e03:5d46:7bca with SMTP id 3f1490d57ef6-e036ec371e1mr9657756276.45.1719941700595; Tue, 02 Jul 2024 10:35:00 -0700 (PDT) MIME-Version: 1.0 References: <202407021715.462HFLqm917034@freefriends.org> In-Reply-To: <202407021715.462HFLqm917034@freefriends.org> From: Dave Hart Date: Tue, 2 Jul 2024 17:34:49 +0000 Message-ID: Subject: Re: bug#71847: Self-inflicted problem, libtool and automake installed to different prefixes To: Karl Berry Content-Type: multipart/alternative; boundary="00000000000019373a061c472237" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 71847 Cc: 71847@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --00000000000019373a061c472237 Content-Type: text/plain; charset="UTF-8" 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 /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 > /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 --00000000000019373a061c472237 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Dave,

=C2=A0 =C2=A0 # wget https://davehart.net/ntp/t= est/ntp-4.2.8p18-vcs.tar.xz
=C2=A0 =C2=A0 # tar xf *p18-vcs*xz
=C2=A0 =C2=A0 # cd *vcs
=C2=A0 =C2=A0 # ./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 undef= ined
..

This is because, as Nick described in
=C2=A0 https://lists.gnu.org/archiv= e/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?):
=C2=A0 aclocal --system-acdir=3D/usr/local/gnu/share/aclocal --verbose -I s= ntp/m4 -I sntp/libevent/m4 -I sntp/libopts/m4
did find libtool.m4 .



A)=C2=A0 Perhaps the prerelease announcements should mention the issue s= omehow (e.g. suggesting also installing libtool to any test prefix, or poin= ting via 'autoreconf -d' or the environment variable).
B)=C2=A0 Perhaps the libtool macros not found error me= ssage could hint at this cause alongside the stuff about ensuring LT_INIT i= s used.

Thanks again,
Dave Hart
--00000000000019373a061c472237-- From debbugs-submit-bounces@debbugs.gnu.org Tue Jul 02 18:24:52 2024 Received: (at 71847) by debbugs.gnu.org; 2 Jul 2024 22:24:52 +0000 Received: from localhost ([127.0.0.1]:38020 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sOlvg-0004TA-35 for submit@debbugs.gnu.org; Tue, 02 Jul 2024 18:24:52 -0400 Received: from frenzy.freefriends.org ([198.99.81.75]:54508 helo=freefriends.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sOlvd-0004Sr-Jo for 71847@debbugs.gnu.org; Tue, 02 Jul 2024 18:24:50 -0400 X-Envelope-From: karl@freefriends.org Received: from freefriends.org (localhost [127.0.0.1]) by freefriends.org (8.16.1/8.16.1) with ESMTPS id 462MOdPW937996 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Tue, 2 Jul 2024 16:24:39 -0600 Received: (from apache@localhost) by freefriends.org (8.16.1/8.14.7/Submit) id 462MOdwr937995; Tue, 2 Jul 2024 16:24:39 -0600 Date: Tue, 2 Jul 2024 16:24:39 -0600 Message-Id: <202407022224.462MOdwr937995@freefriends.org> From: Karl Berry To: davehart@gmail.com Subject: Re: bug#71847: Self-inflicted problem, libtool and automake installed to different prefixes In-Reply-To: X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 71847 Cc: 71847@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) 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 :). Looking into that further, the main external package I test with is TeX Live. Although I had forgotten earlier, for TL we long ago put a copy of libtool.m4 into TL itself (and methods to keep it in sync), to ease exactly this sort of problem. So I believe that's why I have not seen it. A) Perhaps the prerelease announcements should mention the issue somehow [...] B) Perhaps the libtool macros not found error message could hint at this cause alongside the stuff about ensuring LT_INIT is used. Both are good ideas. I'll take a look. Thanks! From debbugs-submit-bounces@debbugs.gnu.org Tue Jul 02 21:00:07 2024 Received: (at 71847) by debbugs.gnu.org; 3 Jul 2024 01:00:07 +0000 Received: from localhost ([127.0.0.1]:38191 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sOoLv-000058-5R for submit@debbugs.gnu.org; Tue, 02 Jul 2024 21:00:07 -0400 Received: from mail-qt1-f182.google.com ([209.85.160.182]:55774) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sOoLs-0008Vj-HD for 71847@debbugs.gnu.org; Tue, 02 Jul 2024 21:00:05 -0400 Received: by mail-qt1-f182.google.com with SMTP id d75a77b69052e-445033fbc24so40001581cf.3 for <71847@debbugs.gnu.org>; Tue, 02 Jul 2024 18:00:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=draconx-ca.20230601.gappssmtp.com; s=20230601; t=1719968337; x=1720573137; darn=debbugs.gnu.org; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=NBk13mJCYyVpYRK2/40E2VPPbCS+zFK7AvnqxL6C5l8=; b=zUA6FNlvRAUQfnEI9DwhSufaqNNcKN7dkYaBrn1ETE33dmMz0R/cKRIOy7GLxYBkiu ShM28BHHRfbGutJ0QRJta4l1WMyu/5+sIpmR/fJ31Q2N8isfRjPbGQqo9tRCIIkF1Jfn xGAamDUxtjabbPv9BPVcoG706rcjXTFgEEuXppeNVqOIwwy7arDYn/bxSdAm65eW+973 xwNAetXSAMF9XIvK6JPwCesQ4f+lrUw5+k21AINml533HyemIzk0vfIsS0dH8u6BrTJI xpZSZIam9rMt1eHBnhd48Y78QF97JBuKZdvCyBZrP9vb4lAg2Xf3jZzQKIlSiX9r7P+u P4YA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1719968337; x=1720573137; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=NBk13mJCYyVpYRK2/40E2VPPbCS+zFK7AvnqxL6C5l8=; b=NDIrDPr1zP95ODEci0onYtyqhw4+WY2j7sTNybGLO4Ic/hbv8Qg2nltnnJXy5mi82g bxCR0f/4VVD52ckEUn4LabJywWPwh6+Cbp9HVyKNUPx+c2/dbuGHFasKkOL4552qCkBq ZVZ88tfvVCXqfQigS7jgClMhH/jRzlJpkhaSInpP7AvdSAJRZc0pIK26CCiPM2WbcWuT RrvqqvvrLdzCR54FZrjHRIOiiGaSDcJ5+N1TEqqFJY06R0NRQJdPpb+FJo90FlMfv1gs dGDVq2iEG+EtMIoIClFPX9X8GyNH3hIujR0+S1mHxSip4GgNXRES0PYmeWQWmpHbozp/ Zv0w== X-Gm-Message-State: AOJu0YxAaWHvZ2EWuPY5OhQna4zmAk2Ed69ofbfLXEzucNZcM/I2+kBc Fn8cb+fT2dTgixygPYDmZPcHelrcTXU77bd2a7hxVt4FoRyXxIbIgy4d/U18FjnEsIKSPdmH032 W X-Google-Smtp-Source: AGHT+IGxK/4KdshtGTNoDVmN1Mfody27FaOCOP3o8ms3LF8nSR7rYH6jeCbu9zVzDqkLXRAP2cIQAg== X-Received: by 2002:ac8:5f08:0:b0:442:2c5f:d2f7 with SMTP id d75a77b69052e-44662dde26fmr126320731cf.31.1719968336950; Tue, 02 Jul 2024 17:58:56 -0700 (PDT) Received: from [192.168.0.50] (dhcp-24-53-241-2.cable.user.start.ca. [24.53.241.2]) by smtp.gmail.com with ESMTPSA id d75a77b69052e-446513db1edsm45637621cf.14.2024.07.02.17.58.56 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 02 Jul 2024 17:58:56 -0700 (PDT) Message-ID: <90a8fbcd-1562-4c3e-adf9-59eff1c9ff14@draconx.ca> Date: Tue, 2 Jul 2024 20:58:55 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#71847: Self-inflicted problem, libtool and automake installed to different prefixes Content-Language: en-US To: Dave Hart References: <202407021715.462HFLqm917034@freefriends.org> From: Nick Bowler In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 71847 Cc: 71847@debbugs.gnu.org, Karl Berry X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) 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 From debbugs-submit-bounces@debbugs.gnu.org Tue Jul 02 23:51:10 2024 Received: (at 71847) by debbugs.gnu.org; 3 Jul 2024 03:51:10 +0000 Received: from localhost ([127.0.0.1]:38321 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sOr1R-0004hr-IT for submit@debbugs.gnu.org; Tue, 02 Jul 2024 23:51:10 -0400 Received: from mail-yb1-f170.google.com ([209.85.219.170]:53723) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sOr1M-0004hh-Az for 71847@debbugs.gnu.org; Tue, 02 Jul 2024 23:51:08 -0400 Received: by mail-yb1-f170.google.com with SMTP id 3f1490d57ef6-e0354459844so4821207276.3 for <71847@debbugs.gnu.org>; Tue, 02 Jul 2024 20:51:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1719978602; x=1720583402; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=ujiqA1hb+MUbnD8VYdJhpeKVMaJg9/VBbqDhy89CoaM=; b=HxiXa50BP5t/q3oOeM7RxFebeoTcaaoGopv3daJ3cbTV4RiHhtXH5NSs0afbqoH3a4 2k4/SuCblQyRptx8vGSgXy6aAjHyrQ50CgGBoWxELlkPS4JQaZ7Ktw5aC0qgfxgV5m+0 qUasJDjSCUWads677E2p63OQ/fDZ/6zcpxBO38oKWkmj2GTv/43/aZUIXbnQebhuosNp k8IA3udlevWXFMzby/zzzRkgqf65otoIzFjkHwCr3oGz+T8BFIR1ZotVx5dpScf9qOql VmSjd7nQmYvYVdhssy809gj0Z2xcqVPIn7sycYGE3FFbNJXw8Tq3okEZQWwoi2pKaEsJ xtCw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1719978602; x=1720583402; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=ujiqA1hb+MUbnD8VYdJhpeKVMaJg9/VBbqDhy89CoaM=; b=E8jejnUbxiWAY2y3esLZyU/RAFiRbGDwdy9G3vPHNwzHtQNnT525IcNnv+ism3IZUg 7C/2ufmzI6m963YaG+1hwVc8pMJoaW8DOhJ7mE4PGRz+u0B/eMb8os2hgo/ICPZz3Vi2 xwabOiXIevwrHiAbZD+1iN0BoL06orrUtsz4SwbrhUnfBjT68oP+IxGRRn4822KQ7adq 0PfI01oGwAc4lIaiUo4EBKvCaSKXbxA4O4xYBx/ho6h8kQzpOLWdxc09UPsMXhGwd9t3 h9zrk2EWUwAGl5bhrNpQnfQs26zG/4tSVs8qKVPo40VufARKhusYKwIOCZMmb6pB0Qs2 /Lew== X-Gm-Message-State: AOJu0YzHGygBN1l6Wwo/4bpVAO4x0/JIS2d4UquH/SU4IkkTNmxjw3kq pQcpBgtDSS8cZIJM2b8RK/iYYPMK5HlHdE34Jc/7uT4y77r943Gh3pTjpgqZG78k4RxwKAPodTZ dtPRjAWC+L7ime9FTfRaQfgIieXs= X-Google-Smtp-Source: AGHT+IELqa86s3ezuDBQKLxIdlpCEV1Xxk/h0OcgNEZ7u8umz7wg0jxzJxZdIAwjqMg8ojFpxt4im0Kolr7JyyPZBbI= X-Received: by 2002:a25:2fc9:0:b0:e03:517b:7cf0 with SMTP id 3f1490d57ef6-e036eb48dd1mr10478650276.25.1719978601767; Tue, 02 Jul 2024 20:50:01 -0700 (PDT) MIME-Version: 1.0 References: <202407021715.462HFLqm917034@freefriends.org> <90a8fbcd-1562-4c3e-adf9-59eff1c9ff14@draconx.ca> In-Reply-To: <90a8fbcd-1562-4c3e-adf9-59eff1c9ff14@draconx.ca> From: Dave Hart Date: Wed, 3 Jul 2024 03:49:50 +0000 Message-ID: Subject: Re: bug#71847: Self-inflicted problem, libtool and automake installed to different prefixes To: Nick Bowler Content-Type: multipart/alternative; boundary="000000000000946fc6061c4fb976" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 71847 Cc: 71847@debbugs.gnu.org, Karl Berry X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --000000000000946fc6061c4fb976 Content-Type: text/plain; charset="UTF-8" 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 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. > The typical bk-based workflow for NTP developers is to start with a clean clone of the repo which does not contain any libtool .m4 files or autotools output, and run the bootstrap script to bring the repo into a similar state as one would get from an extracted make dist tarball. bk doesn't have branches, so we typically always have a 'clean' workspace to start, as each "branch" is another copy of the repo. 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? 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. > Yes, and it's always good to understand these sorts of potential regressions, but it might not justify more investigation given other productive uses of volunteer developers' time if others aren't seeing it. -- Cheers, Dave Hart --000000000000946fc6061c4fb976 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On = Wed, 3 Jul 2024 at 00:58, Nick Bowler <nbowler@draconx.ca> 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.=C2=A0 There are a varie= ty
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.=C2=A0 Then autoreconf will run libtoolize, which copies<= br> 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.=C2=A0= Or if
libtool.m4 has been deleted prior to running autoreconf.=C2=A0 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.

Th= e typical bk-based workflow for NTP developers is to start with a clean clo= ne of the repo which does not contain any libtool .m4 files or autotools ou= tput, and run the bootstrap script to bring the repo into a similar state a= s one would get from an extracted make dist tarball.=C2=A0 bk doesn't h= ave branches, so we typically always have a 'clean' workspace to st= art, as each "branch" is another copy of the repo.

It occurs to me we= might avoid issues along these lines by having our bootstrap script invoke= libtoolize before autoreconf.=C2=A0 Does that sound wise to the two of you= ?

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.

Yes, a= nd it's always good to understand these sorts of=C2=A0potential regress= ions, but it might not justify more investigation given other productive us= es of volunteer developers' time if others aren't seeing it.
<= /div>

--
Cheers,
Dave Hart
--000000000000946fc6061c4fb976-- From debbugs-submit-bounces@debbugs.gnu.org Wed Jul 03 09:38:30 2024 Received: (at 71847) by debbugs.gnu.org; 3 Jul 2024 13:38:30 +0000 Received: from localhost ([127.0.0.1]:39208 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sP0Bp-0001BJ-Oo for submit@debbugs.gnu.org; Wed, 03 Jul 2024 09:38:30 -0400 Received: from mail-yb1-f178.google.com ([209.85.219.178]:45127) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sP0Bn-0001B4-BL for 71847@debbugs.gnu.org; Wed, 03 Jul 2024 09:38:27 -0400 Received: by mail-yb1-f178.google.com with SMTP id 3f1490d57ef6-e035ecb35ffso5365026276.2 for <71847@debbugs.gnu.org>; Wed, 03 Jul 2024 06:38:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1720013840; x=1720618640; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=82MzzXAuKrCKqFPHTjUN3KeC/DeC4eP43/EsYG8Bnus=; b=lCfetj/PMBwsK/BkD8UPs4V/xafDlGJA8GwaDVR7s55H4z76AF2RmIutkAdS4bfX98 TRWGYc4JLzlP9fOnHXnWa+FgmBIHnY/U5tup083P8opetrfF1DjmuShdRfeksyObcdrT XiMvMlcJtT9FQozGRpCLClfIXSqZctgvDMRwLHAwJsVwF74q2T0ygMDP/PxcKQoS4Ur8 P/TEtZd1UChfItRVjeG+Vr5jBRuxRASNkauvwuYAjF1+Y59ADUjvMHJYN2uOSQ9hKD6C er/tQ3N8SENfwSP9fcZqvzjS0XQ1j17DsWP05gm8Vd4fDHkrUsB3/c0Ll0wc/BHipmrP c6Cw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1720013840; x=1720618640; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=82MzzXAuKrCKqFPHTjUN3KeC/DeC4eP43/EsYG8Bnus=; b=eXLI6JogJcXoQfUK5IkCClXoHmnKjkAgqIb+ocQLN5iP8YoA+jKI8BWm0gUKeAUYe+ F2BUuZJZn1+MyLwHibavFKDqkWilbeIcNgbFFCAiPL0MdpN2D2w75wgFGdofrLrgOgQn 8LfP2B+Um1G3yWu3QAGZe1ZANRpbMmIc5Vw3BnLcES7pNdc7s5MxIVS/pwUIXEZeNI2L je2CnK54t4KdK3fk5rCOydzbF/YDfpZWMDqgK3C+p7oXiFltPnPCQku03QERT3x1nZuI qJfpXJdfK7NqvSVCxtK8Z+zITAnswh4S3UCkC13xvk1gwDJETI1BkGPWfokIXorjq/rS q3qQ== X-Gm-Message-State: AOJu0YxnYB/AJ88Xzo3CZgi33gtFPlGvtDSOX4PWL+3P2h97PK62HQRm Ei8uycpmBSs46FVovuREuDGhQQ5jNKy9iomZsfCoGUkbN6fPrEkWs/8kExemhF091bPL6eaJMCz H62hiKOtCkd6WrNqlYZ7RTwyh5sk= X-Google-Smtp-Source: AGHT+IGG8S3Hz/NOptrVpQekv0lrU5Jwu+je9ZHQkRzKNK++01fo7AKto5LjXUe/NW5Su9qv6ONlncZTLzHlyVJtNz0= X-Received: by 2002:a25:aa47:0:b0:e03:b0b6:ae19 with SMTP id 3f1490d57ef6-e03b0b6b01amr1277280276.11.1720013839782; Wed, 03 Jul 2024 06:37:19 -0700 (PDT) MIME-Version: 1.0 References: <202407021715.462HFLqm917034@freefriends.org> <90a8fbcd-1562-4c3e-adf9-59eff1c9ff14@draconx.ca> In-Reply-To: From: Dave Hart Date: Wed, 3 Jul 2024 13:37:08 +0000 Message-ID: Subject: Re: bug#71847: Self-inflicted problem, libtool and automake installed to different prefixes To: Nick Bowler Content-Type: multipart/alternative; boundary="000000000000edda6d061c57edfc" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 71847 Cc: 71847@debbugs.gnu.org, Karl Berry X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --000000000000edda6d061c57edfc Content-Type: text/plain; charset="UTF-8" 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 right thing, but I still see automake decide it't not using libtool. hart@pogo> libtoolize libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, `sntp/libevent/build-aux'. libtoolize: linking file `sntp/libevent/build-aux/ltmain.sh' libtoolize: putting macros in AC_CONFIG_MACRO_DIR, `sntp/m4'. libtoolize: linking file `sntp/m4/libtool.m4' libtoolize: linking file `sntp/m4/ltoptions.m4' libtoolize: linking file `sntp/m4/ltsugar.m4' libtoolize: linking file `sntp/m4/ltversion.m4' libtoolize: linking file `sntp/m4/lt~obsolete.m4' This should be reproducible the same way as earlier comments in this bug, just adding a libtoolize invocation before ./bootstrap -- Cheers, Dave Hart --000000000000edda6d061c57edfc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, 3 Jul 2024 at 03:49, Da= ve Hart <davehart@gmail.com>= ; wrote:

It occurs to me we might avoid = issues along these lines by having our bootstrap script invoke libtoolize b= efore autoreconf.=C2=A0 Does that sound wise to the two of you?

I trie= d this approach and it didn't help.=C2=A0 libtoolize seems to be doing = the right thing, but I still see automake decide it't not=C2=A0using li= btool.

hart@pogo> libtoolize
libtoolize: putting auxiliary files in AC_CO= NFIG_AUX_DIR, `sntp/libevent/build-aux'.
libtoolize: linking file `s= ntp/libevent/build-aux/ltmain.sh'
libtoolize: putting macros in AC_C= ONFIG_MACRO_DIR, `sntp/m4'.
libtoolize: linking file `sntp/m4/libtoo= l.m4'
libtoolize: linking file `sntp/m4/ltoptions.m4'
libtool= ize: linking file `sntp/m4/ltsugar.m4'
libtoolize: linking file `snt= p/m4/ltversion.m4'
libtoolize: linking file `sntp/m4/lt~obsolete.m4&= #39;

This should be reproducible the same way as earlier comments in this b= ug, just adding a libtoolize invocation before ./bootstrap

--=
Cheers,
Dave Hart
--000000000000edda6d061c57edfc-- From debbugs-submit-bounces@debbugs.gnu.org Wed Jul 03 15:53:51 2024 Received: (at 71847) by debbugs.gnu.org; 3 Jul 2024 19:53:51 +0000 Received: from localhost ([127.0.0.1]:40636 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sP634-0003LA-RQ for submit@debbugs.gnu.org; Wed, 03 Jul 2024 15:53:51 -0400 Received: from mail-ot1-f51.google.com ([209.85.210.51]:52472) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sP633-0003Kv-W3 for 71847@debbugs.gnu.org; Wed, 03 Jul 2024 15:53:50 -0400 Received: by mail-ot1-f51.google.com with SMTP id 46e09a7af769-700cbdd90fbso3560954a34.0 for <71847@debbugs.gnu.org>; Wed, 03 Jul 2024 12:53:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=draconx-ca.20230601.gappssmtp.com; s=20230601; t=1720036362; x=1720641162; darn=debbugs.gnu.org; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=3maqYgAmvBOuPNU4eUXGHVJTNugI0AIq8Q21LAKaarE=; b=nR7qPB9G28o3SjRIi02aDXbTeZKnR0dlI0NN3pdzJwekfcRgRvdV7XOPFkdNI22a7v iWy5IdJzX7/uIgx8KBJHluau+oBPhIgsqoF56i1rgEK7NuGxv5Z/9gVYzWiqbXzSiNPe //81uEzG04u4lDz6Vg/Qci/3eP0jYgghsQuDkS490mPLpA51HjOhONaEwXCgJ1bpHNso Z7wXiRkLMkyXYDFB90UAEyZtUBPdncwrVT2Ft85NUXPgFGScbmID1FIu62XMbDX8cvnD Z9qD8SHo7Wb273btyOtZNCEtJQNt/Rx9mgY2g1+qPfEX4Hr3NJLLtEStwNDe2Hj6QuZD ArDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1720036362; x=1720641162; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=3maqYgAmvBOuPNU4eUXGHVJTNugI0AIq8Q21LAKaarE=; b=upLWc20s/yLGJ0LN0N3wh2yNL9ft5j6veO8FYOpHzccU0tpiEX163a+e6IoKfK8aTW lxhBlB0nN6MSNOiIHFw9DuW+EpVlo6Q8KYHgPOXzE3p5TnNzru7KEUkHf5UH2qrcKU2W 38ue/WQ1/s+qUmfX5hkqdJBXpktiFKGiyLosFC3GqrCu+iHkYldIKa4ggnE7yLfM487F qJzgmynHCbP6KWJD7mSFhXdku/WB8R/qsqTZZanryo7q5YQwPw9d3ZPHrfsrRF+WnuWL y3oCmb0zscbgl+Q1GHJCMUzX3NKPMYtvyxedeviMEeIr33om3nqtN2tgx2zCPbCI0evm COEQ== X-Gm-Message-State: AOJu0YxsN9cuCosWv+nszlBZnW3qnv9aVtSd0asoftFeVaYMkbDhjOr0 TkkPlrcC7J4YGLetdghHqSeHxrVVAd02Sui3MZYSO1MjV6dWFbBXOFtLVG2uCtg= X-Google-Smtp-Source: AGHT+IGUK9NaMZjo6JssmwvITE4RiRVbNm8tWEsSY/964MorPPOb1gC9cjlX9yFEi3PxTz5saH3IBQ== X-Received: by 2002:a9d:7483:0:b0:702:1e8c:849d with SMTP id 46e09a7af769-7021e8c8572mr8147469a34.33.1720036362271; Wed, 03 Jul 2024 12:52:42 -0700 (PDT) Received: from [192.168.0.50] (dhcp-24-53-241-2.cable.user.start.ca. [24.53.241.2]) by smtp.gmail.com with ESMTPSA id af79cd13be357-79d69260561sm603288085a.25.2024.07.03.12.52.41 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 03 Jul 2024 12:52:42 -0700 (PDT) Message-ID: <3a4c2352-befe-48e2-8c56-b01ab25896d5@draconx.ca> Date: Wed, 3 Jul 2024 15:52:40 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#71847: Self-inflicted problem, libtool and automake installed to different prefixes Content-Language: en-US To: Dave Hart References: <202407021715.462HFLqm917034@freefriends.org> <90a8fbcd-1562-4c3e-adf9-59eff1c9ff14@draconx.ca> From: Nick Bowler In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 71847 Cc: 71847@debbugs.gnu.org, Karl Berry X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) 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 > 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. 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. Cheers, Nick From debbugs-submit-bounces@debbugs.gnu.org Wed Jul 03 18:11:13 2024 Received: (at 71847) by debbugs.gnu.org; 3 Jul 2024 22:11:13 +0000 Received: from localhost ([127.0.0.1]:40917 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sP8C1-0007Af-Dg for submit@debbugs.gnu.org; Wed, 03 Jul 2024 18:11:13 -0400 Received: from frenzy.freefriends.org ([198.99.81.75]:56216 helo=freefriends.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sP8Bu-0007AN-Rk for 71847@debbugs.gnu.org; Wed, 03 Jul 2024 18:11:11 -0400 X-Envelope-From: karl@freefriends.org Received: from freefriends.org (localhost [127.0.0.1]) by freefriends.org (8.16.1/8.16.1) with ESMTPS id 463MAvIV1056621 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Wed, 3 Jul 2024 16:10:58 -0600 Received: (from apache@localhost) by freefriends.org (8.16.1/8.14.7/Submit) id 463MAvIR1056620; Wed, 3 Jul 2024 16:10:57 -0600 Date: Wed, 3 Jul 2024 16:10:57 -0600 Message-Id: <202407032210.463MAvIR1056620@freefriends.org> From: Karl Berry To: davehart@gmail.com, 71847@debbugs.gnu.org Subject: Re: bug#71847: Self-inflicted problem, libtool and automake installed to different prefixes In-Reply-To: X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 71847 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) 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/libopts/m4 aclocal: found macro SNTP_PROBLEM_TESTS in sntp/m4/sntp_problemtests.m4: 10 .. But I think I need to leave further debugging on that to you ... --best, karl. From debbugs-submit-bounces@debbugs.gnu.org Wed Jul 03 18:11:14 2024 Received: (at 71847) by debbugs.gnu.org; 3 Jul 2024 22:11:14 +0000 Received: from localhost ([127.0.0.1]:40919 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sP8C1-0007Aj-Nh for submit@debbugs.gnu.org; Wed, 03 Jul 2024 18:11:13 -0400 Received: from frenzy.freefriends.org ([198.99.81.75]:56218 helo=freefriends.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sP8Bu-0007AO-Vj for 71847@debbugs.gnu.org; Wed, 03 Jul 2024 18:11:11 -0400 X-Envelope-From: karl@freefriends.org Received: from freefriends.org (localhost [127.0.0.1]) by freefriends.org (8.16.1/8.16.1) with ESMTPS id 463MAw0V1056629 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Wed, 3 Jul 2024 16:10:58 -0600 Received: (from apache@localhost) by freefriends.org (8.16.1/8.14.7/Submit) id 463MAwEf1056628; Wed, 3 Jul 2024 16:10:58 -0600 Date: Wed, 3 Jul 2024 16:10:58 -0600 Message-Id: <202407032210.463MAwEf1056628@freefriends.org> From: Karl Berry To: davehart@gmail.com Subject: Re: bug#71847: Self-inflicted problem, libtool and automake installed to different prefixes In-Reply-To: X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 71847 Cc: nbowler@draconx.ca, 71847@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > 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 find libtool either. Isn't that conclusive? Similarly, if the automake pretest and libtool are installed into the same prefix, then libtool is found. -k From debbugs-submit-bounces@debbugs.gnu.org Thu Jul 04 00:44:19 2024 Received: (at 71847) by debbugs.gnu.org; 4 Jul 2024 04:44:19 +0000 Received: from localhost ([127.0.0.1]:41212 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sPEKQ-0000Y7-QD for submit@debbugs.gnu.org; Thu, 04 Jul 2024 00:44:19 -0400 Received: from mail-yb1-f180.google.com ([209.85.219.180]:46131) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sPEKO-0000Xs-HQ for 71847@debbugs.gnu.org; Thu, 04 Jul 2024 00:44:17 -0400 Received: by mail-yb1-f180.google.com with SMTP id 3f1490d57ef6-dfab5f7e749so242720276.0 for <71847@debbugs.gnu.org>; Wed, 03 Jul 2024 21:44:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1720068189; x=1720672989; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=JhnWmPbnyK1/c47kgD2pSibSUiXkRzUXODEhPvq3Sns=; b=EQKBy8Q8xKIYpKhzaDXl6HeEiYWTS+zRW33w9cWMAsOFNEiswVQu1BbeeXjdPv5tZZ +BRS84S4UKI7WySDfQd3UBzoL8NR4W9SUdROrdUuOcIPCTy/Es7kn7btAqLiq3u/6TuL 3dqKjchk3BjL2NFhkKwRL3+F6t8mCJabcWuNNhiv37Xxlqiorvhlk123ndwvcNRpfJP2 amxL/924ZKTltT7PKpWB5EM2HKCJoz111GqTkhg3RkpWwIwi5tnnvSn8ycVlJFI9pYDx wIPjYtzHZvHGdh7ZYC0mvmGD37Li6ZPcz4WgFPV3UhIucW90wPjqk21McbZSOdGYFLLZ VkDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1720068189; x=1720672989; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=JhnWmPbnyK1/c47kgD2pSibSUiXkRzUXODEhPvq3Sns=; b=TJQnqmhJc/JVf2g2/TcMLr93wKQt/RJWvGuqcHD+pVz22ftsl1pwyGjYnrat157VVF 0NFTeXQdHLS1xuZc+gI+WhtpO05b1ECDOhQvH2z2i4606iWPT5eUJCi8afec7Y9Vchs9 rbspQJJuh8HU7PpSR6W65IDudqJQRh8b73ngMePATe1WBuZJxL3gPTDuyvBkVnW1YhCd Jj2ttcvGAu1VeWOhYxf66FYxB1Jdqc7qKzTZ0StjMC4bQVnhRfz2+Gu3rykcWQMhKZ+j mULw2t2Eqb7JiFK1lpbEzezfkMY8nwm9tzQuKnw1UkLVwNtC7VYgfJ+MrGYv268KAfVh AI+w== X-Gm-Message-State: AOJu0YxIcMNx3ncnrt81SvzFAXssl0+mHAyRHz1fAEkwT2KbS5SAl42d UEpN/oDfGXadhXVTNHUu6N/MxasDj8pZHWTjRNQPsKa7XdE8qO7/WXxszwFwaOEyRvX4gZjGDMm Z9nXq4YWLPnkjpoObiFfYMILldso= X-Google-Smtp-Source: AGHT+IFcLeHNoYpKRjeP1MlbtddGYLdzbb2QlKAV4w/b+SY2DFjZTjRCcBSNxwlKGsfVK65taAY74aVNRB4t2WjTdAM= X-Received: by 2002:a25:2ce:0:b0:e03:b4cc:d9d5 with SMTP id 3f1490d57ef6-e03c193ff8dmr468584276.11.1720068188625; Wed, 03 Jul 2024 21:43:08 -0700 (PDT) MIME-Version: 1.0 References: <202407021715.462HFLqm917034@freefriends.org> <90a8fbcd-1562-4c3e-adf9-59eff1c9ff14@draconx.ca> <3a4c2352-befe-48e2-8c56-b01ab25896d5@draconx.ca> In-Reply-To: <3a4c2352-befe-48e2-8c56-b01ab25896d5@draconx.ca> From: Dave Hart Date: Thu, 4 Jul 2024 04:42:56 +0000 Message-ID: Subject: Re: bug#71847: Self-inflicted problem, libtool and automake installed to different prefixes To: Nick Bowler Content-Type: multipart/alternative; boundary="0000000000005f605f061c6495bc" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 71847 Cc: 71847@debbugs.gnu.org, Karl Berry X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --0000000000005f605f061c6495bc Content-Type: text/plain; charset="UTF-8" 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 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 --0000000000005f605f061c6495bc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, 3 Jul 2024 at 19:52, Ni= ck Bowler <nbowler@draconx.ca&= gt; wrote:
On 2024-07-03 09:37, Dave Hart wrote: > On Wed, 3 Jul 2024 at 03:49, Dave Hart <davehart@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.=C2=A0 libtoolize seems t= o 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 scrip= t to have:

cd sntp/libevent
libtoolize
cd ..
libtoolize
cd ..
li= btoolize

immediately before the autoreconf invocation.=C2=A0 That does work= around the problem, and I can commit that change, though it seems like it&= #39;s going to slow every bootstrap for us (which we do frequently) to work= around a relatively rare issue.
=C2=A0
All of this could probably be improved.=C2=A0 If aclocal provided a default=
stub definition of LT_INIT then everything would probably "just work&q= uot;:
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.=C2=A0 You could perhaps simulate such an effect by putting somethi= ng
like this into acinclude.m4 (for each sub-project):

=C2=A0 m4_pattern_forbid([^LT_INIT$])
=C2=A0 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.=C2=A0 If they were not properly picked up, the dummy expansion
will match the forbidden pattern so autoconf can produce a reasonable
fatal error.

Tha= t sounds like a productive avenue.=C2=A0 That should work to prevent this i= ssue from arising with testing the NTP code against a prerelease Automake i= nstalled in a prefix without libtool, and would probably avoid the slowdown= of three libtoolize invocations before autoreconf in our bootstrap script.= =C2=A0 But wouldn't it be better to make such a solution part of Automa= ke 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
--0000000000005f605f061c6495bc-- From debbugs-submit-bounces@debbugs.gnu.org Thu Jul 04 18:27:47 2024 Received: (at 71847) by debbugs.gnu.org; 4 Jul 2024 22:27:47 +0000 Received: from localhost ([127.0.0.1]:43217 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sPUvb-0002MK-CZ for submit@debbugs.gnu.org; Thu, 04 Jul 2024 18:27:47 -0400 Received: from frenzy.freefriends.org ([198.99.81.75]:45368 helo=freefriends.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sPUvZ-0002MB-Kl for 71847@debbugs.gnu.org; Thu, 04 Jul 2024 18:27:46 -0400 X-Envelope-From: karl@freefriends.org Received: from freefriends.org (localhost [127.0.0.1]) by freefriends.org (8.16.1/8.16.1) with ESMTPS id 464MRa0M1166526 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Thu, 4 Jul 2024 16:27:36 -0600 Received: (from apache@localhost) by freefriends.org (8.16.1/8.14.7/Submit) id 464MRaST1166525; Thu, 4 Jul 2024 16:27:36 -0600 Date: Thu, 4 Jul 2024 16:27:36 -0600 Message-Id: <202407042227.464MRaST1166525@freefriends.org> From: Karl Berry To: davehart@gmail.com Subject: Re: bug#71847: Self-inflicted problem, libtool and automake installed to different prefixes In-Reply-To: X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 71847 Cc: nbowler@draconx.ca, 71847@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) 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 release. Or, more directly, check for $automakeprefix>/share/aclocal*/libtool.m4 and only do the libtoolize if not already there. I mean, where automake_prefix=$(dirname $(which automake))/.. Or something like that. You get the idea, I'm sure :). But wouldn't it be better to make such a solution part of Automake and have it gracefully handle this situation for everyone? Sure, clearly a graceful solution for everyone would be ideal. But in terms of the pending 1.17 release, I don't want to do something as potentially destabilizing as defining a stub LT_INIT in aclocal. That seems like it has great potential for confusion and problems. Also, looking at Automake/Variable.pm, there are a bunch of various/functions handled in the same way, e.g., CC vs. AC_PROG_CC just like LIBTOOL vs. LT_INIT. Although I think LT_INIT is the only one not defined by Automake or Autoconf. At any rate, It would also be nice to see an actual patch, since my knowledge of aclocal/automake<->libtool interaction is limited, at best, so I'm not sure offhand where or how to make such a change. Meanwhile, I'll at least tweak the (test relese) NEWS and error message as you suggested. --thanks, karl. From debbugs-submit-bounces@debbugs.gnu.org Thu Jul 04 20:28:42 2024 Received: (at 71847) by debbugs.gnu.org; 5 Jul 2024 00:28:42 +0000 Received: from localhost ([127.0.0.1]:43291 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sPWoc-0005dU-16 for submit@debbugs.gnu.org; Thu, 04 Jul 2024 20:28:42 -0400 Received: from mail-yb1-f176.google.com ([209.85.219.176]:44297) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sPWoZ-0005dF-GG for 71847@debbugs.gnu.org; Thu, 04 Jul 2024 20:28:40 -0400 Received: by mail-yb1-f176.google.com with SMTP id 3f1490d57ef6-e03c6892e31so853469276.1 for <71847@debbugs.gnu.org>; Thu, 04 Jul 2024 17:28:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1720139251; x=1720744051; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=pHkJzuagJ9Q1TUE8C1xJPhIAb2qPx16KXlzsuhshvcU=; b=OiEzJhXJdtH7rH0qppi/AljjuEG6jpVD3iROU06hbWlkKaYNyxsvu5utu4NAGI7nvB 0Iam8dLJt+8E1xc87uEkYP+OQ49wB1lCCAQkQHR99okWkTLBNqmwTKiVbmZjqwiePzGT pr5caojkm4v2hA88uRnQUj6N2RacDuUrNPvGFtcbvFAibHJUJ/TNoLkVHMBfHUqx2se4 5ITXMD3xh+rlwrs2wOJt9iMFGPVW36LawNSgSMuDNGGxJeEnQCAyOtnfHsSPluqkpZ2i lmXt+Go9Yj6aRjem7W/Bx57edEPARfvPCmo2pKViie0nzL4UQz0K0ILj8OGm1DcyDcI6 eq6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1720139251; x=1720744051; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=pHkJzuagJ9Q1TUE8C1xJPhIAb2qPx16KXlzsuhshvcU=; b=BndgLATLa+qekDD95wZ1B1uzBX2nlnyHP7QUlY1MqdhcYCsviGW032UGFREOKpvKJl 2gR15k5n0vbc3lLe15dDs9jeOCjfqwAWjcTOEHzSmMhBM+uM9WvKgwRxionzbcGe6KyW 6+o3ebQ+1e/fHXIB/maZlMSrWcjv5fF/fm9nz43gDrTEWJyTE+wc9kiJCVDgl7Bq+cdf 7POwCn1iClyLli2TbBWTX5PqVzDgH04Gzi6uhaECEE9zg+EvMEOrY8X4+zJmG5DOfzS1 g3QpcdXSVAw4kdKL3RK7zvCgKANavXSGobmipJ1CKyXdJBuVA01Ssy9qvXkI3PUoNanL UQjQ== X-Forwarded-Encrypted: i=1; AJvYcCVBWoP470++5NgWCrYGAkZY8qYlrw/0MSgH6TRuqD79Q6G9XoITq18rdzJYZ3FcoSbvTvXIz8Kbrh8FLIiIVhki00LQXO4= X-Gm-Message-State: AOJu0YwpLYHpp3iH/Y+uu/e8lJYeKFnOuFlY+YWr6Ptglze79ZGXoh1b rlQaWWaCegqVu7MGc+rMiTcr9uSE0C1jgu22wDPfDLH7YZzL0hVt+paOmU+stlL/3MpBNKcF0y0 q5CwSL51ujC6xgA2H6UBgVf0GgwI= X-Google-Smtp-Source: AGHT+IF0wNfLR/AFNSp66bUCmVaj6z7TWE9q46xOA4/Oi9TtgZm09Sp0UcM6SUWU/S1t9lqB+Hfhucn8IBjnEDXV5A0= X-Received: by 2002:a25:c50c:0:b0:e03:5dfe:45c8 with SMTP id 3f1490d57ef6-e03c1b72ad7mr2843146276.64.1720139250843; Thu, 04 Jul 2024 17:27:30 -0700 (PDT) MIME-Version: 1.0 References: <202407042227.464MRaST1166525@freefriends.org> In-Reply-To: <202407042227.464MRaST1166525@freefriends.org> From: Dave Hart Date: Fri, 5 Jul 2024 00:27:19 +0000 Message-ID: Subject: Re: bug#71847: Self-inflicted problem, libtool and automake installed to different prefixes To: Karl Berry Content-Type: multipart/alternative; boundary="00000000000002c762061c75210c" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 71847 Cc: nbowler@draconx.ca, 71847@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --00000000000002c762061c75210c Content-Type: text/plain; charset="UTF-8" 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 only > if the automake --version is x.y.9*, i.e., a test release. Or, more > directly, check for $automakeprefix>/share/aclocal*/libtool.m4 and only > do the libtoolize if not already there. I mean, where > automake_prefix=$(dirname $(which automake))/.. > Or something like that. You get the idea, I'm sure :). > 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, and I'd rather put my effort into a general fix for everyone. But wouldn't it be better to make such a solution part of Automake > and have it gracefully handle this situation for everyone? > > Sure, clearly a graceful solution for everyone would be ideal. But in > terms of the pending 1.17 release, I don't want to do something as > potentially destabilizing as defining a stub LT_INIT in aclocal. That > seems like it has great potential for confusion and problems. > Understood, I'm not trying to hold up 1.17. I initially raised that possibility because I didn't understand how corner-case it was. > Also, looking at Automake/Variable.pm, there are a bunch of > various/functions handled in the same way, e.g., CC vs. AC_PROG_CC > just like LIBTOOL vs. LT_INIT. Although I think LT_INIT is the only one > not defined by Automake or Autoconf. > > At any rate, It would also be nice to see an actual patch, since my > knowledge of aclocal/automake<->libtool interaction is limited, at best, > so I'm not sure offhand where or how to make such a change. > My perl skills are nearly zero, though I'm sure I can figure it out with enough effort. Perhaps raising the issue on the automake mailing list would be productive in terms of soliciting suggestions on how to implement this corner case improvement. Meanwhile, I'll at least tweak the (test relese) NEWS and error message > as you suggested. --thanks, karl. > Thank you. -- Cheers, Dave Hart --00000000000002c762061c75210c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, 4 Jul 2024 at 22:27, Ka= rl Berry <karl@freefriends.org> wrote:
=C2=A0 =C2=A0 slow every bootstrap fo= r us (which we do frequently) to work around a
=C2=A0 =C2=A0 relatively rare issue.

Nick's solution of using acinclude.m4 seems ideal. But just in case: I<= br> 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 release. Or, more
directly, check for $automakeprefix>/share/aclocal*/libtool.m4 and only<= br> do the libtoolize if not already there.=C2=A0 I mean, where
=C2=A0 automake_prefix=3D$(dirname $(which automake))/..
Or something like that. You get the idea, I'm sure :).
=

While I agree I can avoid t= his problem with the acinclude.m4 approach, I'm hesitant to do so becau= se it's a corner case we don't hit that often, and I'd rather p= ut my effort into a general fix for everyone.

=C2=A0 =C2=A0 But wouldn't it be be= tter to make such a solution part of Automake
=C2=A0 =C2=A0 and have it gracefully handle this situation for everyone?
Sure, clearly a graceful solution for everyone would be ideal. But in
terms of the pending 1.17 release, I don't want to do something as
potentially destabilizing as defining a stub LT_INIT in aclocal. That
seems like it has great potential for confusion and problems.

Understood, I'm not = trying to hold up 1.17.=C2=A0 I initially raised that possibility because I= didn't understand how corner-case it was.
=C2=A0
=
Also, looking at Automake= /Variable.pm, there are a bunch of
various/functions handled in the same way, e.g., CC vs. AC_PROG_CC
just like LIBTOOL vs. LT_INIT. Although I think LT_INIT is the only one
not defined by Automake or Autoconf.

At any rate, It would also be nice to see an actual patch, since my
knowledge of aclocal/automake<->libtool interaction is limited, at be= st,
so I'm not sure offhand where or how to make such a change.

My perl skills are nea= rly zero, though I'm sure I can figure it out with enough effort.=C2=A0= Perhaps raising the issue on the automake mailing list would be productive= in terms of soliciting suggestions on how to implement this corner case im= provement.

Meanwhile, I'll at least tweak the (test relese) NEWS and error message=
as you suggested. --thanks, karl.

Thank= you.


= --
<= font face=3D"trebuchet ms, sans-serif">Cheers,
Dave Hart
--00000000000002c762061c75210c-- From debbugs-submit-bounces@debbugs.gnu.org Sat Jul 06 18:34:08 2024 Received: (at 71847) by debbugs.gnu.org; 6 Jul 2024 22:34:08 +0000 Received: from localhost ([127.0.0.1]:46934 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sQDyq-0006f2-1u for submit@debbugs.gnu.org; Sat, 06 Jul 2024 18:34:08 -0400 Received: from frenzy.freefriends.org ([198.99.81.75]:43642 helo=freefriends.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sQDyn-0006eu-ON for 71847@debbugs.gnu.org; Sat, 06 Jul 2024 18:34:06 -0400 X-Envelope-From: karl@freefriends.org Received: from freefriends.org (localhost [127.0.0.1]) by freefriends.org (8.16.1/8.16.1) with ESMTPS id 466MXt1W1370909 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Sat, 6 Jul 2024 16:33:55 -0600 Received: (from apache@localhost) by freefriends.org (8.16.1/8.14.7/Submit) id 466MXtK61370908; Sat, 6 Jul 2024 16:33:55 -0600 Date: Sat, 6 Jul 2024 16:33:55 -0600 Message-Id: <202407062233.466MXtK61370908@freefriends.org> From: Karl Berry To: davehart@gmail.com Subject: Re: bug#71847: Self-inflicted problem, libtool and automake installed to different prefixes In-Reply-To: X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 71847 Cc: nbowler@draconx.ca, 71847@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) 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.m4(s) would help move towards the general fix, since it would give us some real-world experience with that "error stub", to see if there are any unexpected problems. My perl skills are nearly zero This particular issue seems to be all about m4 and autoconf, not so much Perl :). Perhaps raising the issue on the automake mailing list I think everyone on the automake list who might actually do any work is also on bug-automake :). --thanks, karl. From debbugs-submit-bounces@debbugs.gnu.org Mon Jul 08 18:05:34 2024 Received: (at 71847) by debbugs.gnu.org; 8 Jul 2024 22:05:34 +0000 Received: from localhost ([127.0.0.1]:51639 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sQwUF-00047V-98 for submit@debbugs.gnu.org; Mon, 08 Jul 2024 18:05:34 -0400 Received: from frenzy.freefriends.org ([198.99.81.75]:42610 helo=freefriends.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sQwU9-00047F-BN for 71847@debbugs.gnu.org; Mon, 08 Jul 2024 18:05:29 -0400 X-Envelope-From: karl@freefriends.org Received: from freefriends.org (localhost [127.0.0.1]) by freefriends.org (8.16.1/8.16.1) with ESMTPS id 468M5DS81567150 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Mon, 8 Jul 2024 16:05:13 -0600 Received: (from apache@localhost) by freefriends.org (8.16.1/8.14.7/Submit) id 468M5Dm91567149; Mon, 8 Jul 2024 16:05:13 -0600 Date: Mon, 8 Jul 2024 16:05:13 -0600 Message-Id: <202407082205.468M5Dm91567149@freefriends.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="6Mp9riKx/1" Content-Transfer-Encoding: 7bit From: Karl Berry To: davehart@gmail.com, 71847@debbugs.gnu.org Subject: Re: bug#71847: Self-inflicted problem, libtool and automake installed to different prefixes In-Reply-To: X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 71847 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --6Mp9riKx/1 Content-Type: text/plain; charset=iso-8859-1 Content-Description: message body text Content-Transfer-Encoding: 8bit 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 making a hello,world using libtool (attached for my own memory :), I found that just running aclocal -I... did not suffice. After the aclocal run, the next error was: configure.ac:9: error: required file './ltmain.sh' not found just as already described in the manual (preceding node). So running libtoolize is needed, not just playing with -I options, as far as I can tell. I also discovered that although libtoolize only asks you to "consider" creating an m4/ subdir for macros, in fact it is a requirement, at least in the case of automake and libtool in different prefixes. Without AC_CONFIG_MACRO_DIRS([m4]), the original "error: Libtool library used but 'LIBTOOL' is undefined" persists. (Aside: It was also rather irritating to have to run automake --add-missing three separate times as new pieces were found. Oh well.) It's all quite a confusing conglomeration, but I don't think there's anything to do about here. I guess I will leave this open in hopes of figuring out that m4 stub approach, but this is all I can see to do for the 1.17 release. (I've got nothing else pending for 1.17, so if anyone knows of a reason to delay, let me know asap.) --thanks, karl. ----------------------------------------------------------------------------- automake: info about Automake and Libtool being in different prefixes. In response to https://bugs.gnu.org/71847. * doc/automake.texi (Libtool library used but LIBTOOL is undefined): new node. Tweak aclocal section. * lib/Automake/Variable.pm (require_variables): refer to the new node in the message for LT_INIT. * maintainer/maint.mk (announcement) : new fn; use it to output a link to the new node for test releases only. * HACKING: mention M-x texinfo-master-menu, et al. diff --git a/HACKING b/HACKING index 085ebcee5..1573d9fba 100644 --- a/HACKING +++ b/HACKING @@ -99,7 +99,7 @@ We used to use '_am_' as the prefix for an internal AC_SUBSTs. However, it turns out that NEWS-OS 4.2R complains if a Makefile variable begins with the underscore character. Yay for them. - I changed the target naming convention just to be safe. + We changed the target naming convention just to be safe. * If you'd like to read some general background on automake and the other GNU autotools, you might try this not-too-long web page (not @@ -118,7 +118,7 @@ * Never use basename or dirname. Instead, use sed. -* Do not use 'cd' within back-quotes, use '$(am__cd)' instead. +* Do not use 'cd' within backquotes, use '$(am__cd)' instead. Otherwise the directory name may be printed, depending on CDPATH. More generally, do not ever use plain 'cd' together with a relative directory that does not start with a dot, or you might end up in one @@ -133,7 +133,7 @@ nothing is to be actually installed. See automake bug#11030. ============================================================================ -= Editing automake.in and aclocal.in += Editing conventions * Indent using GNU style. For historical reasons, the perl code contains portions indented using Larry Wall's style (perl-mode's @@ -141,7 +141,19 @@ default). Write new code using GNU style. * Don't use & for function calls, unless really required. - The use of & prevents prototypes from being checked. + The use of & prevents prototypes from being checked; it's also + uncommon in modern Perl code. + (Perl prototypes are unlike function prototypes in other + languages, so understand what they do.) + +* For automake.texi: + - After and during editing, run make info for error checking, and make pdf + to catch TeX-only errors. + - After adding a new node, you can update the @detailmenu with + M-x texinfo-master-menu (not tested with current Emacs releases, but + hopefully it still works). + - You'll probably have already added it to the higher-level menu under + which the new node was added, since that's necessary to run "make info". ============================================================================ = Automake versioning and compatibility scheme @@ -375,7 +387,8 @@ can also parallelize the makes that run inside each test with, e.g.: make check AM_TESTSUITE_MAKE="make -j$(( 1*$(nproc) + 1 ))" If you like, try different levels of parallelization to see what - runs the fastest on your machine. We'll use -j12 in this document. + runs the fastest on your machine. We'll use -j12 in our examples; + adjust as needed. * To summarize, here is a typical make check invocation: make -j12 VERBOSE=1 check keep_testdirs=yes @@ -401,8 +414,9 @@ * After "make -j12 check" succeeds. Run "make -j12 distcheck" before pushing a commit, since that exercises yet more of the code. -* To un-silence (some) of what make does, use make V=1. - For yet more verbosity, make VERBOSE=1. +* To unsilence Automake's "pretty" output for debugging, see the + "Unsilencing Automake" node in the manual. In short: run make --debug=p. + For the Automake test suite in particular, add VERBOSE=1. * To set up a new test, first write the test file in t/good-name.sh. Choose a name that fits with existing ones, as best you can devise. diff --git a/doc/automake.texi b/doc/automake.texi index 4bfff91c3..49ebfb2b2 100644 --- a/doc/automake.texi +++ b/doc/automake.texi @@ -181,7 +181,7 @@ Scanning @file{configure.ac}, using @command{aclocal} * aclocal Invocation:: Auto-generating aclocal.m4 * Macros:: Autoconf macros supplied with Automake -Auto-generating aclocal.m4 +Auto-generating aclocal.m4: Invoking @command{aclocal} * aclocal Options:: Options supported by aclocal * Macro Search Path:: How aclocal finds .m4 files @@ -256,6 +256,7 @@ Building a Shared Library Common Issues Related to Libtool's Use * Error required file ltmain.sh not found:: The need to run libtoolize +* Libtool library used but LIBTOOL is undefined:: test releases and libtoolize * Objects created both with libtool and without:: Avoid a specific build race Yacc and Lex support @@ -301,8 +302,8 @@ Python Building documentation -* Texinfo:: Texinfo -* Man Pages:: Man pages +* Texinfo:: +* Man Pages:: What Gets Installed @@ -1606,7 +1607,7 @@ Autoconf distribution), and @noindent If needed, tools related to Gettext (@pxref{,,,gettext, GNU gettext -utilities}) and Libtool (@pxref{,,,libtool, GNU libtool}) are also +utilities}) and Libtool (@pxref{,,,libtool, The Libtool Manual}) are also invoked at different points. Thus, as you can see, using @command{autoreconf} is quite a bit more convenient. @@ -2612,7 +2613,7 @@ would be chosen by automake; they would be @file{false-true.o} and @file{true-true.o}. (The name of the object files rarely matters.) @node automake Invocation -@chapter Creating a @file{Makefile.in} +@chapter Creating a @file{Makefile.in}: Invoking @command{automake} @c This node used to be named "Invoking automake". This @anchor @c allows old links to still work. @anchor{Invoking automake} @@ -3275,7 +3276,7 @@ macros installed in a system-wide directory; @pxref{aclocal Invocation}). @end ftable @node aclocal Invocation -@section Auto-generating aclocal.m4 +@section Auto-generating aclocal.m4: Invoking @command{aclocal} @c This node used to be named "Invoking aclocal". This @anchor @c allows old links to still work. @anchor{Invoking aclocal} @@ -3317,14 +3318,14 @@ specified as a relative search path with @command{aclocal}'s @option{-I} argument, @command{aclocal} assumes the file belongs to the package and uses @code{m4_include} instead of copying it into @file{aclocal.m4}. This makes the package smaller, eases dependency -tracking, and cause the file to be distributed automatically. +tracking, and causes the file to be distributed automatically. (@xref{Local Macros}, for an example.) Any macro that is found in a system-wide directory or via an absolute search path will be copied. So use @samp{-I `pwd`/reldir} instead of @samp{-I reldir} whenever -some relative directory should be considered outside the package. +a relative directory should be considered to be outside the package. The contents of @file{acinclude.m4}, if this file exists, are also -automatically included in @file{aclocal.m4}. We recommend against +automatically included in @file{aclocal.m4}. We mostly recommend against using @file{acinclude.m4} in new packages (@pxref{Local Macros}). @vindex AUTOM4TE @@ -3338,11 +3339,12 @@ conditionally). @command{autom4te} is expected to be in the @env{PATH}, just like @command{autoconf}. Its location can be overridden using the @env{AUTOM4TE} environment variable. -Although this section explains the details of @command{aclocal}, in -practice it is usually simpler to run @command{autoreconf}, instead of -worrying about the required order of the various tools -(@pxref{autoreconf Invocation, , Using @command{autoreconf}, -autoconf, The Autoconf Manual}). +In practice it is usually simpler to run @command{autoreconf} instead +of worrying about the required order of the various tools +(@pxref{autoreconf Invocation, , Using @command{autoreconf}, autoconf, +The Autoconf Manual}). + +This section explains the details of @command{aclocal}. @menu * aclocal Options:: Options supported by aclocal @@ -3364,13 +3366,14 @@ autoconf, The Autoconf Manual}). @table @code @item --automake-acdir=@var{dir} @opindex --automake-acdir -Look for the automake-provided macro files in @var{dir} instead of +Look for Automake-provided macro files in @var{dir} instead of in the installation directory. This is typically used for debugging. @vindex ACLOCAL_AUTOMAKE_DIR -The environment variable @env{ACLOCAL_AUTOMAKE_DIR} provides another -way to set the directory containing automake-provided macro files. -However @option{--automake-acdir} takes precedence over it. +If this option is not specified, the value of the environment variable +@env{ACLOCAL_AUTOMAKE_DIR}, if set, is used to set the directory +containing Automake-provided macro files. Otherwise an install-time +default is used. @item --aclocal-path=@var{path} @opindex --aclocal-path @@ -3381,9 +3384,10 @@ used for building against alternative system roots (``sysroots'') for finding headers and libraries.) @vindex ACLOCAL_PATH -The environment variable @env{ACLOCAL_PATH} provides another way to -set the search path containing local third-party macro files. This -variable is ignored if the @option{--aclocal-path} option is specified. +If this option is not specified, the value of the environment variable +@env{ACLOCAL_PATH}, if set, is used to set the search path containing +local third-party macro files. Otherwise an install-time default is +used. @item --system-acdir=@var{dir} @opindex --system-acdir @@ -3404,7 +3408,7 @@ by @option{--install}. @item --help @opindex --help -Print a summary of the command line options and exit. +Print a summary of the command line options and exit successfully. @item -I @var{dir} @opindex -I @@ -3414,10 +3418,10 @@ Add the directory @var{dir} to the list of directories searched for @item --install @opindex --install Install system-wide third-party macros into the first directory -specified with @samp{-I @var{dir}} instead of copying them in the +specified with @samp{-I @var{dir}} instead of copying them into the output file. @c Keep in sync with aclocal-install-absdir.sh -Note that this will happen also if @var{dir} is an absolute path. +This is also done if @var{dir} is an absolute path. @cindex serial number and @option{--install} When this option is used, and only when this option is used, @@ -3433,8 +3437,8 @@ output file only when needed, i.e., when its contents change or if one of its dependencies is younger. This option forces the update of @file{aclocal.m4} (or the file -specified with @file{--output} below) and only this file, it has -absolutely no influence on files that may need to be installed by +specified with @file{--output} below) and only this file; it has no +influence on files that may need to be installed by @option{--install}. @item --output=@var{file} @@ -3443,40 +3447,42 @@ Cause the output to be put into @var{file} instead of @file{aclocal.m4}. @item --print-ac-dir @opindex --print-ac-dir -Prints the name of the directory that @command{aclocal} will search to +Print the name of the directory that @command{aclocal} will search to find third-party @file{.m4} files. When this option is given, normal processing is suppressed. This option was used @emph{in the past} by third-party packages to determine where to install @file{.m4} macro files, but @emph{this usage is today discouraged}, since it causes -@samp{$(prefix)} not to be thoroughly honored (which violates the -GNU Coding Standards), and similar semantics can be better obtained -with the @env{ACLOCAL_PATH} environment variable; @pxref{Extending aclocal}. +@samp{$(prefix)} not to be thoroughly honored (violating the GNU +Coding Standards). And similar semantics can be better obtained with +the @env{ACLOCAL_PATH} environment variable (@pxref{Extending +aclocal}). @item --verbose @opindex --verbose -Print the names of the files it examines. +Print the names of files examined. @item --version @opindex --version -Print the version number of Automake and exit. +Print the version number of Automake and exit successfully. @item -W CATEGORY @item --warnings=@var{category} @opindex -W @opindex --warnings -Output warnings falling in @var{category}. @var{category} can be -one of: +Output warnings falling in @var{category}, one of: @table @code @item syntax dubious syntactic constructs, underquoted macros, unused macros, etc. @item unsupported -unknown macros +unknown macros. @item all -all the warnings, this is the default +all the warnings; this is the default. @item none -turn off all the warnings +turn off all the warnings. +@item no-@var{category} +turn off warnings in @var{category}. @item error -treat warnings as errors +treat warnings as errors. @end table All warnings are output by default. @@ -3504,14 +3510,14 @@ for example, for Automake 1.11.x, @var{APIVERSION} = @code{1.11}. @item @var{acdir} This directory is intended for third party @file{.m4} files, and is -configured when @command{automake} itself is built. This is +configured when @command{automake} itself is built. It is @file{@@datadir@@/aclocal/}, which typically expands to @file{$@{prefix@}/share/aclocal/}. To find the compiled-in value of @var{acdir}, use the @option{--print-ac-dir} option (@pxref{aclocal Options}). @end table -As an example, suppose that @command{automake-1.11.2} was configured with +For example, suppose that Automake 1.11.2 was configured with @option{--prefix=@-/usr/local}. Then, the search path would be: @enumerate @@ -3519,20 +3525,20 @@ As an example, suppose that @command{automake-1.11.2} was configured with @item @file{/usr/local/share/aclocal/} @end enumerate -The paths for the @var{acdir} and @var{acdir-APIVERSION} directories can -be changed respectively through aclocal options @option{--system-acdir} -and @option{--automake-acdir} (@pxref{aclocal Options}). Note however -that these options are only intended for use by the internal Automake -test suite, or for debugging under highly unusual situations; they are -not ordinarily needed by end-users. +The paths for the @var{acdir} and @var{acdir-APIVERSION} directories +can be changed respectively through the @command{aclocal} options +@option{--system-acdir} and @option{--automake-acdir} (@pxref{aclocal +Options}). These options are not ordinarily needed by end-users; +they're mainly intended for use by the Automake test suite, or for +debugging. -As explained in (@pxref{aclocal Options}), there are several options that -can be used to change or extend this search path. +As also listed in (@pxref{aclocal Options}), several other options can +be used to change or extend the macro search path. @subsubheading Modifying the Macro Search Path: @samp{-I @var{dir}} -Any extra directories specified using @option{-I} options -(@pxref{aclocal Options}) are @emph{prepended} to this search list. Thus, +Any directories specified using @option{-I} options (@pxref{aclocal +Options}) are @emph{prepended} to this search list. Thus, @samp{aclocal -I /foo -I /bar} results in the following search path: @enumerate @@ -3546,12 +3552,13 @@ Any extra directories specified using @option{-I} options @subsubheading Modifying the Macro Search Path: @file{dirlist} @cindex @file{dirlist} -There is a third mechanism for customizing the search path. If a -@file{dirlist} file exists in @var{acdir}, then that file is assumed to -contain a list of directory patterns, one per line. @command{aclocal} -expands these patterns to directory names, and adds them to the search -list @emph{after} all other directories. @file{dirlist} entries may -use shell wildcards such as @samp{*}, @samp{?}, or @code{[...]}. +There is a third mechanism for customizing the search path: if a +@file{dirlist} file exists in @var{acdir}, then that file is assumed +to contain a list of directory patterns, one per line. +@command{aclocal} expands these patterns to directory names, and adds +them to the search list @emph{after} all other directories. +@file{dirlist} entries may use shell wildcards such as @samp{*}, +@samp{?}, or @code{[...]}. For example, suppose @file{@var{acdir}/dirlist} contains the following: @@ -3574,20 +3581,16 @@ Then, the search path would be @item @var{acdir} @item @code{/test1} @item @code{/test2} +@item all directories with path names starting with @code{/test3}. @end enumerate -@noindent -and all directories with path names starting with @code{/test3}. - If the @option{--system-acdir=@var{dir}} option is used, then -@command{aclocal} will search for the @file{dirlist} file in -@var{dir}; but remember the warnings above against the use of -@option{--system-acdir}. +@command{aclocal} will search for the @file{dirlist} file in that +@var{dir}. @file{dirlist} is useful in the following situation: suppose that -@command{automake} version @code{1.11.2} is installed with -@samp{--prefix=/usr} by the system vendor. Thus, the default search -directories are +Automake 1.11.2 is installed with @samp{--prefix=/usr} by the system +vendor. Thus, the default search directories are @c @code looks better than @file here @enumerate @@ -3596,13 +3599,14 @@ directories are @end enumerate However, suppose further that many packages have been manually -installed on the system, with $prefix=/usr/local, as is typical. In -that case, many of these ``extra'' @file{.m4} files are in -@file{/usr/local/share/aclocal}. The only way to force -@file{/usr/bin/aclocal} to find these ``extra'' @file{.m4} files is to -always call @samp{aclocal -I /usr/local/share/aclocal}. This is -inconvenient. With @file{dirlist}, one may create a file -@file{/usr/share/aclocal/dirlist} containing only the single line +installed on the system, with @code{$prefix=/usr/local}, as is +typical. In that case, many of these ``extra'' @file{.m4} files are +in @file{/usr/local/share/aclocal}. Without @file{dirlist}, the only +way to force @file{/usr/bin/aclocal} to find these ``extra'' +@file{.m4} files is to always call @samp{aclocal -I +/usr/local/share/aclocal}. This is inconvenient. With +@file{dirlist}, one can create a file +@file{/usr/share/aclocal/dirlist} containing the single line @example /usr/local/share/aclocal @@ -3618,10 +3622,9 @@ Now, the ``default'' search path on the affected system is @end enumerate @noindent -without the need for @option{-I} options; @option{-I} options can be reserved -for project-specific needs (@file{my-source-dir/m4/}), rather than -using them to work around local system-dependent tool installation -directories. +This way, @option{-I} options can be reserved for project-specific +needs (@file{my-source-dir/m4/}), rather than using them to work +around local system-dependent tool installation directories. Similarly, @file{dirlist} can be handy if you have installed a local copy of Automake in your account and want @command{aclocal} to look for @@ -3632,13 +3635,14 @@ macros installed at other places on the system. @opindex @option{--aclocal-path} @cindex @env{ACLOCAL_PATH} -The fourth and last mechanism to customize the macro search path is -also the simplest. Any directory included in the colon-separated path -given to the @option{--aclocal-path} command-line option or in the -@env{ACLOCAL_PATH} environment variable is added to the search path. +The fourth and last mechanism to customize the macro search path: any +directory included in the colon-separated path given to the +@option{--aclocal-path} command-line option, or (if the option is not +specified) in the @env{ACLOCAL_PATH} environment variable, is added to +the search path. @c Keep in sync with aclocal-path-precedence.sh -These directories take precedence over system directories (including -those found via @file{dirlist}), with the exception of the versioned +These directories take precedence over system directories, including +those found via @file{dirlist}, with the exception of the versioned directory @var{acdir-APIVERSION} (@pxref{Macro Search Path}). However, directories passed via @option{-I} will take precedence over directories in @option{--aclocal-path}/@env{ACLOCAL_PATH}. @@ -3651,12 +3655,12 @@ containing a required macro that is found in a directory listed in In this case, serial numbers in @file{.m4} are honored too (@pxref{Serials}). -Conversely to @file{dirlist}, @option{--aclocal-path}/@env{ACLOCAL_PATH} is useful if you are using a global copy of Automake and want @command{aclocal} to look for -macros somewhere under your home directory. +macros somewhere under your home directory. This is more or less the +opposite of @file{dirlist}. -@subsubheading Possible future incompatibility +@subsubheading Possible future incompatibility in @command{aclocal} The order in which the directories in the macro search path are currently looked up is confusing and/or suboptimal in various aspects. @@ -3664,10 +3668,10 @@ In particular, directories in @option{--aclocal-path}/@env{ACLOCAL_PATH} and @file{@var{acdir}} might end up taking precedence over @file{@var{acdir-APIVERSION}}, and directories in @file{@var{acdir}/dirlist} might end up taking -precedence over @file{@var{acdir}}. Although there are no plans to -change the current behavior, if it causes problems, the default might -need to be changed, and the current behavior retained as an -option. +precedence over @file{@var{acdir}}. There are no definite plans to +change the current behavior, but if bug reports show the need (so +please report issues), the default might need to be changed, and the +current behavior retained as an option. @node Extending aclocal @subsection Writing your own aclocal macros @@ -3675,17 +3679,17 @@ option. @cindex @command{aclocal}, extending @cindex Extending @command{aclocal} -The @command{aclocal} program doesn't have any built-in knowledge of any -macros, so it is easy to extend it with your own macros. +The @command{aclocal} program doesn't have built-in knowledge of any +macros. You can extend it with your own macros. -This can be used by libraries that want to supply their own Autoconf +Libraries, for example, usually want to supply their own Autoconf macros for use by other programs. For instance, the @command{gettext} library supplies a macro @code{AM_GNU_GETTEXT} that should be used by -any package using @command{gettext}. When the library is installed, it -installs this macro so that @command{aclocal} will find it. +any package using @command{gettext}. When the library is installed, +it installs this macro so that @command{aclocal} will find it. A macro file's name should end in @file{.m4}. Such files should be -installed in @file{$(datadir)/aclocal}. This is as simple as writing: +installed in @file{$(datadir)/aclocal}. This can be done with: @c Keep in sync with primary-prefix-couples-documented-valid.sh @example @@ -3697,19 +3701,19 @@ aclocal_DATA = mymacro.m4 myothermacro.m4 Please do use @file{$(datadir)/aclocal}, and not something based on the result of @samp{aclocal --print-ac-dir} (@pxref{Hard-Coded Install Paths}, for arguments). It might also be helpful to suggest to -the user to add the @file{$(datadir)/aclocal} directory to his +the user to add the @file{$(datadir)/aclocal} directory to their @env{ACLOCAL_PATH} variable (@pxref{ACLOCAL_PATH}) so that @command{aclocal} will find the @file{.m4} files installed by your package automatically. A file of macros should be a series of properly quoted @code{AC_DEFUN}'s (@pxref{Macro Definitions, , , autoconf, The -Autoconf Manual}). The @command{aclocal} programs also understands +Autoconf Manual}). The @command{aclocal} program also understands @code{AC_REQUIRE} (@pxref{Prerequisite Macros, , , autoconf, The Autoconf Manual}), so it is safe to put each macro in a separate file. -Each file should have no side effects but macro definitions. -Especially, any call to @code{AC_PREREQ} should be done inside the -defined macro, not at the beginning of the file. +Each file should have no side effects except for defining the +macro(s). In particular, any call to @code{AC_PREREQ} should be done +inside the defined macro, not at the beginning of the file. @cindex underquoted @code{AC_DEFUN} @acindex AC_DEFUN @@ -3720,13 +3724,13 @@ underquoted calls to @code{AC_DEFUN}. We realize this annoys some people, because @command{aclocal} was not so strict in the past and many third party macros are underquoted; and we have to apologize for this temporary inconvenience. The reason we have to be stricter is -that a future implementation of @command{aclocal} (@pxref{Future of -aclocal}) will have to temporarily include all of these third party -@file{.m4} files, maybe several times, even including files that end -up not being needed. Doing so should alleviate many problems of the -current implementation; however, it requires a stricter style from -macro authors. Hopefully it is easy to revise the existing macros. -For instance, +that a possible future implementation of @command{aclocal} +(@pxref{Future of aclocal}) will have to temporarily include all of +these third party @file{.m4} files, maybe several times, even +including files that end up not being needed. Doing so should +alleviate many problems of the current implementation; however, it +requires a stricter style from macro authors. Hopefully it is easy to +revise the existing macros. For instance, @example # bad style @@ -3750,20 +3754,19 @@ AX_BAR ]) @end example -Wrapping the @code{AC_PREREQ} call inside the macro ensures that -Autoconf 2.68 will not be required if @code{AX_FOOBAR} is not used. -Most importantly, quoting the first argument of @code{AC_DEFUN} allows -the macro to be redefined or included twice (otherwise this first -argument would be expanded during the second definition). For -consistency we like to quote even arguments such as @code{2.68} that -do not require it. +Wrapping the @code{AC_PREREQ([2.68])} call inside the macro ensures +that the Autoconf 2.68 will not be a prerequisite if @code{AX_FOOBAR} +is not used. Most importantly, quoting the first argument of +@code{AC_DEFUN} allows the macro to be redefined or included twice +(otherwise this first argument would be expanded during the second +definition). For consistency we like to quote even arguments such as +@code{2.68} that do not require it. If you have been directed here by the @command{aclocal} diagnostic but are not the maintainer of the implicated macro, you will want to -contact the maintainer of that macro. Please make sure you have the -latest version of the macro and that the problem hasn't already been -reported before doing so: people tend to work faster when they aren't -flooded by mails. +contact the maintainer of that macro. Please try to make sure you +have the latest version of the macro and that the problem hasn't +already been reported before doing so. Another situation where @command{aclocal} is commonly used is to manage macros that are used locally by the package; @ref{Local @@ -3785,22 +3788,23 @@ henceforth be visible to @command{autoconf}. However, if it contains numerous macros, it will rapidly become difficult to maintain, and it will be almost impossible to share macros between packages. -The second possibility, which we do recommend, is to write each macro -in its own file and gather all these files in a directory. This -directory is usually called @file{m4/}. Then it's enough to update -@file{configure.ac} by adding a proper call to @code{AC_CONFIG_MACRO_DIRS}: +The second possibility, which we recommend, is to write each macro in +its own file and gather all these files in a directory. This +directory is usually called @file{m4/}. Then you can update +@file{configure.ac} by adding a proper call to +@code{AC_CONFIG_MACRO_DIRS}: @example AC_CONFIG_MACRO_DIRS([m4]) @end example @command{aclocal} will then take care of automatically adding @file{m4/} -to its search path for m4 files. +to its search path for M4 files. -When @samp{aclocal} is run, it will build an @file{aclocal.m4} -that @code{m4_include}s any file from @file{m4/} that defines a -required macro. Macros not found locally will still be searched in -system-wide directories, as explained in @ref{Macro Search Path}. +When @command{aclocal} is run, it will build an @file{aclocal.m4} that +@code{m4_include}s any file from @file{m4/} that defines a required +macro. Macros not found locally will still be searched in system-wide +directories, as explained in @ref{Macro Search Path}. Custom macros should be distributed for the same reason that @file{configure.ac} is: so that other people have all the sources of @@ -3808,23 +3812,22 @@ your package if they want to work on it. In fact, this distribution happens automatically because all @code{m4_include}d files are distributed. -However there is no consensus on the distribution of third-party -macros that your package may use. Many libraries install their own -macro in the system-wide @command{aclocal} directory (@pxref{Extending -aclocal}). For instance, Guile ships with a file called -@file{guile.m4} that contains the macro @code{GUILE_FLAGS} that can -be used to define setup compiler and linker flags appropriate for -using Guile. Using @code{GUILE_FLAGS} in @file{configure.ac} will -cause @command{aclocal} to copy @file{guile.m4} into -@file{aclocal.m4}, but as @file{guile.m4} is not part of the project, -it will not be distributed. Technically, that means a user who -needs to rebuild @file{aclocal.m4} will have to install Guile first. -This is probably OK, if Guile already is a requirement to build the -package. However, if Guile is only an optional feature, or if your -package might run on architectures where Guile cannot be installed, -this requirement will hinder development. An easy solution is to copy -such third-party macros in your local @file{m4/} directory so they get -distributed. +There is no consensus on the distribution of third-party macros that +your package may use. Many libraries install their own macro in the +system-wide @command{aclocal} directory (@pxref{Extending aclocal}). +For instance, Guile ships with a file called @file{guile.m4} that +contains the macro @code{GUILE_FLAGS} that can be used to define +compiler and linker flags appropriate for using Guile. Using +@code{GUILE_FLAGS} in @file{configure.ac} will cause @command{aclocal} +to copy @file{guile.m4} into @file{aclocal.m4}, but as @file{guile.m4} +is not part of the project, it will not be distributed. Technically, +that means a user who needs to rebuild @file{aclocal.m4} will have to +install Guile first. This is probably OK, if Guile already is a +requirement to build the package. However, if Guile is only an +optional feature, or if your package might run on architectures where +Guile cannot be installed, this requirement will hinder development. +An easy solution is to copy such third-party macros in your local +@file{m4/} directory so they get distributed. Since Automake 1.10, @command{aclocal} offers the option @code{--install} to copy these system-wide third-party macros in your local macro directory, @@ -3840,19 +3843,10 @@ after the first run is that when you later edit @file{configure.ac} and depend on a new macro, this macro will be installed in your @file{m4/} automatically. Another one is that serial numbers (@pxref{Serials}) can be used to update the macros in your source tree -automatically when new system-wide versions are installed. A serial -number should be a single line of the form - -@example -#serial @var{nnn} -@end example - -@noindent -where @var{nnn} contains only digits and dots. It should appear in -the M4 file before any macro definition. It is a good practice to -maintain a serial number for each macro you distribute, even if you do -not use the @option{--install} option of @command{aclocal}: this allows -other people to use it. +automatically when new system-wide versions are installed. It is good +practice to maintain a serial number for each macro you distribute, +even if you do not use the @option{--install} option of +@command{aclocal}: this allows other people to use it. @node Serials @@ -3863,11 +3857,11 @@ other people to use it. @cindex @command{aclocal} and serial numbers Because third-party macros defined in @file{*.m4} files are naturally -shared between multiple projects, some people like to version them. -This makes it easier to tell which of two M4 files is newer. Since at -least 1996, the tradition is to use a @samp{#serial} line for this. +shared between multiple projects, people like to version them. This +makes it easier to tell which of two M4 files is newer. Since at +least 1996, the convention is to use a @samp{#serial} line for this. -A serial number should be a single line of the form +Such a serial number should be a single line of the form @example # serial @var{version} @@ -3895,9 +3889,11 @@ exist in your search path, and if at least one of them uses a @samp{#serial} line, @command{aclocal} will ignore the file that has the older @samp{#serial} line (or the file that has none). -Note that a serial number applies to a whole M4 file, not to any macro -it contains. A file can contain multiple macros, but only one -serial. +A serial number applies to a whole M4 file, not to any macro it +contains. A file can contain multiple macros, but only one serial +number. + +@subsubheading Serial Number Example Here is a use case that illustrates the use of @option{--install} and its interaction with serial numbers. Let's assume we maintain a @@ -3997,8 +3993,8 @@ If you are leery of letting @command{aclocal} update your local macro, you can run @samp{aclocal --diff} to review the changes @samp{aclocal --install} would perform on these macros. -Finally, note that the @option{--force} option of @command{aclocal} has -absolutely no effect on the files installed by @option{--install}. For +Finally, note that the @option{--force} option of @command{aclocal} +has no effect on the files installed by @option{--install}. For instance, if you have modified your local macros, do not expect @option{--install --force} to replace the local macros by their system-wide versions. If you want to do so, simply erase the local @@ -4012,46 +4008,43 @@ macros you want to revert, and run @samp{aclocal --install}. Ideally, @command{aclocal} should not be part of Automake. Automake should focus on generating @file{Makefile}s; dealing with M4 macros is more Autoconf's job. The fact that some people install Automake just -to use @command{aclocal}, but do not use @command{automake} otherwise -is an indication of how that feature is misplaced. +to use @command{aclocal}, but do not use Automake otherwise, is an +indication of how that feature is misplaced. -The new implementation will probably be done slightly differently. -For instance, it could enforce the @file{m4/}-style layout discussed in +A new implementation would probably be done slightly differently. For +instance, it could enforce the @file{m4/}-style layout discussed in @ref{Local Macros}. -We do not know when or whether this will happen. This has been -discussed several times in the past, but someone still has to commit -to that non-trivial task. +We do not know when or whether this will happen. It has been +discussed several times, but someone still has to commit to executing +this non-trivial task. -From the user point of view, @command{aclocal}'s removal might turn +From the user's point of view, @command{aclocal}'s removal might turn out to be painful. There is a simple precaution that you may take to make that switch more seamless: never call @command{aclocal} yourself. -Keep its invocation under the exclusive control of @command{autoreconf} and -Automake's rebuild rules. Hopefully you won't need to worry about -things breaking; when @command{aclocal} disappears, because everything -will have been taken care of. If otherwise you used to call -@command{aclocal} directly yourself or from some script, you will -quickly notice the change. +Keep its invocation under the exclusive control of +@command{autoreconf} and Automake's rebuild rules. Hopefully you +won't need to worry about things breaking; when @command{aclocal} +disappears, because everything will have been taken care of. If +otherwise you used to call @command{aclocal} directly yourself or from +some script, you will quickly notice the change. Many packages come with a script called @file{bootstrap} or -@file{autogen.sh}, that will just call @command{aclocal}, -@command{libtoolize}, @command{gettextize} or @command{autopoint}, -@command{autoconf}, @command{autoheader}, and @command{automake} in -the right order. In fact, this is precisely what @command{autoreconf} -can do for you. If your package has such a @file{bootstrap} or -@file{autogen.sh} script, consider using @command{autoreconf}. That -should simplify its logic a lot (less things to maintain, all to the -good), it's even likely you will not need the script anymore, and more -to the point you will not call @command{aclocal} directly anymore. +@file{autogen.sh} that calls @command{aclocal}, @command{libtoolize}, +@command{gettextize} or @command{autopoint}, @command{autoconf}, +@command{autoheader}, and @command{automake} in the right order. In +fact, this is precisely what @command{autoreconf} can do for you. If +your package has such a @file{bootstrap} or @file{autogen.sh} script, +consider using @command{autoreconf}. That should simplify its logic +(all to the good), and more to the point you will not call +@command{aclocal} directly anymore. For the time being, third-party packages should continue to install public macros into @file{/usr/share/aclocal/}. If @command{aclocal} is replaced by another tool it might make sense to rename the directory, but supporting @file{/usr/share/aclocal/} for backward -compatibility should be easy provided all macros are properly written -(@pxref{Extending aclocal}). - - +compatibility should be feasible, provided all macros are properly +written (@pxref{Extending aclocal}). @node Macros @section Autoconf macros supplied with Automake @@ -4414,7 +4407,7 @@ been constructed. In addition to the built-in recursive targets defined by Automake (@code{all}, @code{check}, etc.), the developer can also define his own recursive targets. That is done by passing the names of such -targets as arguments to the m4 macro @code{AM_EXTRA_RECURSIVE_TARGETS} +targets as arguments to the M4 macro @code{AM_EXTRA_RECURSIVE_TARGETS} in @file{configure.ac}. Automake generates rules to handle the recursion for such targets; and the developer can define real actions for them by defining corresponding @code{-local} targets. @@ -5196,7 +5189,7 @@ name of the primary is @code{LIBRARIES}. Libraries can be installed in @code{libdir} or @code{pkglibdir}. @xref{A Shared Library}, for information on how to build shared -libraries using libtool and the @code{LTLIBRARIES} primary. +libraries using Libtool and the @code{LTLIBRARIES} primary. Each @code{_LIBRARIES} variable is a list of the libraries to be built. For instance, to create a library named @file{libcpio.a}, but not install @@ -5302,17 +5295,16 @@ macro, libtool, The Libtool Manual}.) @cindex suffix @file{.lo}, defined Because object files for shared and static libraries must be compiled -differently, libtool is also used during compilation. Object files -built by libtool are called @dfn{libtool objects}: these are files +differently, Libtool is also used during compilation. Object files +built by Libtool are called @dfn{libtool objects}: these are files using the @file{.lo} suffix. Libtool libraries are built from these libtool objects. You should not assume anything about the structure of @file{.la} or -@file{.lo} files and how libtool constructs them: this is libtool's -concern, and the last thing one wants is to learn about libtool's -guts. However the existence of these files matters, because they are -used as targets and dependencies in @file{Makefile}s' rules when -building libtool libraries. There are situations where you may have +@file{.lo} files and how Libtool constructs them; this is Libtool's +concern. However, the existence of these files matters, because they +are used as targets and dependencies in @file{Makefile} rules when +building Libtool libraries. There are situations where you may have to refer to these, for instance when expressing dependencies for building source files conditionally (@pxref{Conditional Libtool Sources}). @@ -5320,14 +5312,14 @@ Sources}). @cindex @file{libltdl}, introduction People considering writing a plug-in system, with dynamically loaded -modules, should look into @file{libltdl}: libtool's dlopening library +modules, should look into @file{libltdl}: Libtool's dlopening library (@pxref{Using libltdl, , Using libltdl, libtool, The Libtool Manual}). -This offers a portable dlopening facility to load libtool libraries +This offers a portable dlopening facility to load Libtool libraries dynamically, and can also achieve static linking where unavoidable. -Before we discuss how to use libtool with Automake in detail, it -should be noted that the libtool manual also has a section about how -to use Automake with libtool (@pxref{Using Automake, , Using Automake +Before we discuss how to use Libtool with Automake in detail, it +should be noted that the Libtool manual also has a section about how +to use Automake with Libtool (@pxref{Using Automake, , Using Automake with Libtool, libtool, The Libtool Manual}). @node Libtool Libraries @@ -5341,9 +5333,9 @@ with Libtool, libtool, The Libtool Manual}). @vindex pkglib_LTLIBRARIES @vindex _LTLIBRARIES -Automake uses libtool to build libraries declared with the +Automake uses Libtool to build libraries declared with the @code{LTLIBRARIES} primary. Each @code{_LTLIBRARIES} variable is a -list of libtool libraries to build. For instance, to create a libtool +list of Libtool libraries to build. For instance, to create a libtool library named @file{libgettext.la}, and install it in @code{libdir}, write: @@ -5385,7 +5377,7 @@ hello_LDADD = libgettext.la @noindent Whether @file{hello} is statically or dynamically linked with @file{libgettext.la} is not yet known: this will depend on the -configuration of libtool and the capabilities of the host. +configuration of Libtool and the capabilities of the host. @node Conditional Libtool Libraries @@ -5398,14 +5390,14 @@ two main ways to build conditional libraries: using Automake conditionals or using Autoconf @code{AC_SUBST}itutions. The important implementation detail you have to be aware of is that -the place where a library will be installed matters to libtool: it +the place where a library will be installed matters to Libtool: it needs to be indicated @emph{at link-time} using the @option{-rpath} option. For libraries whose destination directory is known when Automake runs, Automake will automatically supply the appropriate @option{-rpath} -option to libtool. This is the case for libraries listed explicitly in -some installable @code{_LTLIBRARIES} variables such as +option to @command{libtool}. This is the case for libraries listed +explicitly in some installable @code{_LTLIBRARIES} variables such as @code{lib_LTLIBRARIES}. However, for libraries determined at configure time (and thus @@ -5500,14 +5492,14 @@ endif @vindex noinst_LTLIBRARIES @vindex check_LTLIBRARIES -Sometimes you want to build libtool libraries that should not be +Sometimes you want to build Libtool libraries that should not be installed. These are called @dfn{libtool convenience libraries} and are typically used to encapsulate many sublibraries, later gathered into one big installed library. Libtool convenience libraries are declared by directory-less variables such as @code{noinst_LTLIBRARIES}, @code{check_LTLIBRARIES}, or even -@code{EXTRA_LTLIBRARIES}. Unlike installed libtool libraries they do +@code{EXTRA_LTLIBRARIES}. Unlike installed Libtool libraries they do not need an @option{-rpath} flag at link time (this is in fact the only difference). @@ -5519,7 +5511,7 @@ rules to build them, but if the library does not appear as a @file{Makefile} dependency anywhere it won't be built (this is why @code{EXTRA_LTLIBRARIES} is used for conditional compilation). -Here is a sample setup merging libtool convenience libraries from +Here is a sample setup merging Libtool convenience libraries from subdirectories into one main @file{libtop.la} library. @c Keep in sync with ltconv.sh @@ -5591,8 +5583,8 @@ to list in @code{libtop_la_SOURCES} there is no point in cheating with @cindex libtool modules @cindex @option{-module}, libtool -These are libtool libraries meant to be dlopened. They are -indicated to libtool by passing @option{-module} at link-time. +These are Libtool libraries meant to be dlopened. They are +indicated to @command{libtool} by passing @option{-module} at link-time. @example pkglib_LTLIBRARIES = mymodule.la @@ -5631,9 +5623,9 @@ variable should be used to list extra libtool objects (@file{.lo} files) or libtool libraries (@file{.la}) to add to @var{library}. The @samp{@var{library}_LDFLAGS} variable is the place to list -additional libtool linking flags, such as @option{-version-info}, -@option{-static}, and a lot more. @xref{Link mode, , Link mode, -libtool, The Libtool Manual}. +additional @command{libtool} linking flags, such as +@option{-version-info}, @option{-static}, and a lot more. @xref{Link +mode,,, libtool, The Libtool Manual}. The @command{libtool} command has two kinds of options: mode-specific options and generic options. Mode-specific options such as the @@ -5649,8 +5641,8 @@ be listed in the @samp{@var{library}_LIBTOOLFLAGS} variable. If @samp{@var{library}_LIBTOOLFLAGS} is not defined, then the variable @code{AM_LIBTOOLFLAGS} is used instead. -These flags are passed to libtool after the @option{--tag=@var{tag}} -option computed by Automake (if any), so +These flags are passed to @command{libtool} after the +@option{--tag=@var{tag}} option computed by Automake (if any), so @samp{@var{library}_LIBTOOLFLAGS} (or @code{AM_LIBTOOLFLAGS}) is a good place to override or supplement the @option{--tag=@var{tag}} setting. @@ -5688,12 +5680,13 @@ performed automatically by Autoconf (@pxref{AC_LIBOBJ vs LIBOBJS, , @subsection Common Issues Related to Libtool's Use @menu -* Error required file ltmain.sh not found:: The need to run libtoolize +* Error required file ltmain.sh not found:: The need to run libtoolize +* Libtool library used but LIBTOOL is undefined:: aclocal and test releases * Objects created both with libtool and without:: Avoid a specific build race @end menu @node Error required file ltmain.sh not found -@subsubsection Error: @samp{required file `./ltmain.sh' not found} +@subsubsection Error: @samp{required file './ltmain.sh' not found}---@command{libtoolize} needed @cindex @file{ltmain.sh} not found @cindex @command{libtoolize}, no longer run by @command{automake} @cindex @command{libtoolize} and @command{autoreconf} @@ -5702,7 +5695,7 @@ performed automatically by Autoconf (@pxref{AC_LIBOBJ vs LIBOBJS, , @cindex @file{autogen.sh} and @command{autoreconf} Libtool comes with a tool called @command{libtoolize} that will -install libtool's supporting files into a package. Running this +install Libtool's supporting files into a package. Running this command will install @file{ltmain.sh}. You should execute it before @command{aclocal} and @command{automake}. @@ -5715,16 +5708,97 @@ Since Automake 1.6, it has been decided that running @command{libtoolize} was not Automake's business. Instead, that functionality has been moved into the @command{autoreconf} command (@pxref{autoreconf Invocation, , Using @command{autoreconf}, autoconf, -The Autoconf Manual}). If you do not want to remember what to run and -when, just remember the @command{autoreconf} command. Hopefully, -replacing existing @file{bootstrap} or @file{autogen.sh} scripts by a -call to @command{autoreconf} should also free you from any similar -incompatible change in the future. +The Autoconf Manual}). The @command{autoreconf} command saves you +from having to figure out which infrastructure scripts to run in what +order. Augmenting existing @file{bootstrap} or @file{autogen.sh} +scripts with a call to @command{autoreconf} should also free you from +any similar incompatible change in the future. + +@node Libtool library used but LIBTOOL is undefined +@subsubsection Error: @samp{Libtool library used but 'LIBTOOL' is undefined}---@command{libtoolize} redux +@cindex Libtool library used but @samp{LIBTOOL} is undefined +@cindex @samp{LIBTOOL} is undefined + +This error message results from Automake seeing Libtool being used in +@file{Makefile.am}, but the @code{LIBTOOL} variable is not defined. +There are two common reasons for this. First, @code{LT_INIT} is +missing from @file{configure.ac}; it can simply be added. + +The second reason is more complicated: if you've installed Automake +under a separate prefix, Automake cannot know where to find the +@code{LT_INIT} macro. Automake looks in the @file{aclocal.m4} file, +which is generated by the @command{aclocal} command (@pxref{aclocal +Invocation}). But since the default search paths for @command{aclocal} +are based on where it is installed (@pxref{Macro Search Path}), if +Automake is installed in one place (e.g., because it's for a test +release), and Libtool in another (e.g., for general system use), +@file{libtool.m4} won't be found by @command{aclocal} and thus +@code{LT_INIT} won't be defined. + +The best solution is to run @command{libtoolize} in the tree that is +using the separately-installed Automake. That will copy +@file{libtool.m4} and the other Libtool M4 files and scripts into your +package, including @file{ltmain.sh} (see previous section). If you +have subpackages that use Libtool independently, you'll need to run +@command{libtoolize} in each of them. @xref{Invoking libtoolize,,, +libtool, The Libtool Manual}. + +The @command{libtoolize} output suggests using an @file{m4} subdirectory: + +@example +libtoolize: Consider adding 'AC_CONFIG_MACRO_DIRS([m4])' to configure.ac, +libtoolize: and rerunning libtoolize and aclocal. +libtoolize: Consider adding '-I m4' to ACLOCAL_AMFLAGS in Makefile.am. +@end example + +For purposes of Libtool and Automake, however, an m4 subdirectory is +required, not just something to consider. Without having the Libtool +M4 files in the local package, @command{aclocal} will (frustratingly) +report the same @samp{Libtool library used but ...} error. (The name +of the subdirectory for the M4 files can be anything, but @samp{m4} is +by far the most common convention.) + +Here is a concrete example. Suppose you've installed a test +release of Automake (thank you) with @code{--prefix=/tmp/amtest}, and +thus put @code{/tmp/amtest/bin} first in your @env{PATH}. You already +have Libtool installed under @code{/usr/local/gnu}. Then, your +Libtool-using package will fail to bootstrap, with the error: + +@example +Makefile.am:161: error: Libtool library used but 'LIBTOOL' is undefined +... +@end example + +You can resolve this by ensuring your @file{configure.ac} includes +these lines (after the @code{AM_INIT_AUTOMAKE}): + +@example +AC_CONFIG_MACRO_DIRS([m4]) +AM_PROG_AR +LT_INIT +@end example + +@noindent +and then running: + +@example +libtoolize +autoreconf +@end example + +@noindent +To summarize, the @command{libtoolize} (from the system directory) +copies @file{libtool.m4} and the other Libtool support files into your +package. The subsequent @command{autoreconf} then runs +@command{aclocal} (under the test prefix) which can now find +@code{LT_INIT}. + +(For more discussion of this, see @url{https://bugs.gnu.org/71847}. @node Objects created both with libtool and without @subsubsection Objects @samp{created with both libtool and without} -Sometimes, the same source file is used both to build a libtool +Sometimes, the same source file is used both to build a Libtool library and to build another non-libtool target (be it a program or another library). @@ -5746,7 +5820,7 @@ libfoo_la_SOURCES = foo.c @dots{} Technically, it means that we should build @file{foo.$(OBJEXT)} for @file{prog}, and @file{foo.lo} for @file{libfoo.la}. The problem is -that in the course of creating @file{foo.lo}, libtool may erase (or +that in the course of creating @file{foo.lo}, Libtool may erase (or replace) @file{foo.$(OBJEXT)}, and this cannot be avoided. Therefore, when Automake detects this situation it will complain @@ -5797,7 +5871,7 @@ This variable, if it exists, lists all the source files that are compiled to build the program. These files are added to the distribution by default. When building the program, Automake will cause each source file to be compiled to a single @file{.o} file (or -@file{.lo} when using libtool). Normally these object files are named +@file{.lo} when using Libtool). Normally these object files are named after the source file, but other factors can change this. If a file in the @code{_SOURCES} variable has an unrecognized extension, Automake will do one of two things with it. If a suffix rule exists for turning @@ -5877,8 +5951,8 @@ Extra objects can be added to a @emph{library} using the @code{_LIBADD} variable. For instance, this should be used for objects determined by @command{configure} (@pxref{A Library}). -In the case of libtool libraries, @code{maude_LIBADD} can also refer -to other libtool libraries. +In the case of Libtool libraries, @code{maude_LIBADD} can also refer +to other Libtool libraries. @item maude_LDADD Extra objects (@file{*.$(OBJEXT)}) and libraries (@file{*.a}, @@ -6101,8 +6175,8 @@ from @file{test1.cpp}, @file{test2.cpp}, and @file{test3.cpp}. Without the last line, they will be built from @file{test1.c}, @file{test2.c}, and @file{test3.c}. -@cindex Libtool modules, default source example -@cindex default source, Libtool modules example +@cindex libtool modules, default source example +@cindex default source, libtool modules example Another case where this is convenient is building many Libtool modules (@file{module@var{n}.la}), each defined in its own file (@file{module@var{n}.c}). @@ -11483,7 +11557,7 @@ it will cause @command{automake} to output the rules for the respective files only for the given condition. @end defmac -@code{AM_COND_IF} macros may be nested when m4 quotation is used +@code{AM_COND_IF} macros may be nested when M4 quotation is used properly (@pxref{M4 Quotation, ,, autoconf, The Autoconf Manual}). @cindex Example conditional @code{AC_CONFIG_FILES} @@ -11706,8 +11780,8 @@ func.c:4:3: warning: ‘i’ used uninitialized in this function @end example @cindex silent rules and libtool -Also, in projects using @command{libtool}, the use of silent rules can -automatically enable the @command{libtool}'s @option{--silent} option: +Also, in projects using Libtool, the use of silent rules can +automatically enable @command{libtool}'s @option{--silent} option: @example % @kbd{cat Makefile.am} @@ -11849,8 +11923,9 @@ option is still required with GNU @command{make} if the With the @code{AM_SILENT_RULES} macro described in the previous section, Automake does a good job reducing @command{make} output to a -bare minimum. Sometimes you want to see more than that. Let's -summarize ways to get more information out of Automake packages: +bare minimum. Sometimes you want to see more than that, especially +when debugging. Let's summarize ways to get more information out of +Automake packages: @itemize @item @@ -11869,13 +11944,13 @@ Adding @code{AM_V_GEN= AM_V_at=} will unsilence more rules. Thus, in all: @item Even this will not unsilence everything. To see the real truth of what gets executed, resort to GNU Make's debugging feature: @code{make ---debug=p ... other args ...}. This reports every command being run, -ignoring the @code{@@} prefix on rules (which silences them). In the -case of Automake, these commands are generally complex shell -constructs, and you'll want to track down the source files in Automake -to actually understand them; but at least you'll have the text to -search for. You may wish to include other debugging -options. @xref{Options Summary,,,make, The GNU Make Manual}. +--debug=p ... @var{otherargs} ...}. This reports every command being +run, ignoring the @code{@@} prefix on rules (which is what silences +them). In the case of Automake, these commands are generally complex +shell constructs, and you'll want to track down the source files in +Automake to actually understand them; but at least you'll have the +text to search for. You may wish to include other debugging options. +@xref{Options Summary,,,make, The GNU Make Manual}. @end itemize @@ -12288,7 +12363,6 @@ Some of the files that can be automatically installed via the have a special exception allowing you to distribute them with your package, regardless of the licensing you choose. - @node API Versioning @chapter Automake API Versioning @@ -13653,8 +13727,9 @@ generated by @command{automake} effectively: @itemize @item If less verbose output has been enabled in the package with the use -of silent rules (@pxref{Automake Silent Rules}), you can use -@code{make V=1} to see the commands being executed. +of silent rules (@pxref{Automake Silent Rules}), you'll probably want +undo that and see the actual commands being run: @pxref{Unsilencing +Automake}. @item @code{make -n} can help show what would be done without actually doing @@ -13667,9 +13742,9 @@ rules, you should not mix such recursion with actions that change any files.@footnote{Automake's @samp{dist} and @samp{distcheck} rules had a bug in this regard in that they created directories even with @option{-n}, but this has been fixed in Automake 1.11.} Furthermore, -note that GNU @command{make} will update prerequisites for the -@file{Makefile} file itself even with @option{-n} (@pxref{Remaking -Makefiles,,, make, The GNU Make Manual}). +GNU @command{make} will update prerequisites for the @file{Makefile} +file itself even with @option{-n} (@pxref{Remaking Makefiles,,, make, +The GNU Make Manual}). @item @code{make SHELL="/bin/bash -vx"} can help debug complex rules. @@ -13765,7 +13840,6 @@ attach the @file{test-suite.log} file. @printindex cp - @bye @c LocalWords: texinfo setfilename settitle setchapternewpage texi direntry diff --git a/lib/Automake/Variable.pm b/lib/Automake/Variable.pm index f97aab59f..9c004f55d 100644 --- a/lib/Automake/Variable.pm +++ b/lib/Automake/Variable.pm @@ -1175,11 +1175,19 @@ sub require_variables ($$$@) $text .= " The usual way to define '$var' is to add " . "'$mac'\n to '$configure_ac' and run 'aclocal' and " . "'autoconf' again."; + # # aclocal will not warn about undefined macros unless it # starts with AM_. - $text .= "\n If '$mac' is in '$configure_ac', make sure\n" + $text .= "\n\n If '$mac' is in '$configure_ac', make sure\n" . " its definition is in aclocal's search path." unless $mac =~ /^AM_/; + # + # More hints for the libtool case. + $text .= "\n\n If you install Automake in its own prefix,\n" + . " you'll need to arrange for the Libtool m4 files\n" + . " to be found by aclocal. For info on this, see:\n" + . " https://gnu.org/s/automake/manual/automake.html#Libtool-library-used-but-LIBTOOL-is-undefined" + if $mac eq "LT_INIT"; } elsif (exists $_ac_macro_for_var{$var}) { diff --git a/maintainer/maint.mk b/maintainer/maint.mk index a8833ae21..2c5bdbd1b 100644 --- a/maintainer/maint.mk +++ b/maintainer/maint.mk @@ -299,6 +299,7 @@ announcement: NEWS && $(determine_release_type) \ && ftp_base="https://$$dest.gnu.org/gnu/$(PACKAGE)" \ && X () { printf '%s\n' "$$*" >> $@-t; } \ + && AO () { if test "$$dest" = alpha; then X "$$*"; else :; fi; } \ && X "We are pleased to announce the $(PACKAGE_NAME) $(VERSION)" \ "$$announcement_type." \ && X \ @@ -327,6 +328,11 @@ announcement: NEWS && X \ && X "-*-*-*-" \ && X \ + && AO "If you install this test release in its own prefix (recommended)" \ + && AO "and you use libtool, you'll need to arrange for the libtool m4 files"\ + && AO "to be found by aclocal. For info on this, see:" \ + && AO " https://gnu.org/s/automake/manual/automake.html#Libtool-library-used-but-LIBTOOL-is-undefined" \ + && AO \ && $(AWK) '\ ($$0 ~ /^New in .*:/) { wait_for_end=1; } \ (/^~~~/ && wait_for_end) { print; exit(0) } \ compile finished at Mon Jul 8 09:36:14 2024 --6Mp9riKx/1 Content-Type: application/octet-stream Content-Disposition: attachment; filename="amlibtool.tar.gz" Content-Transfer-Encoding: base64 H4sIAAAAAAAAA+1ZXW/aSBTl2b/ibvpCWuL4Ex7SXa1jSIoKITJGfYgqy9gDjGJ70HjcNFrt f9+ZgRio2qK04DZaHyEGj+982HfOmXuHME3wlBGSnDeOBo2j07FFqXdsXV5zPJXyt261LVPT LdsyGpqu20anAfbxprRBkbOQAjTuQ5p8z44SwqqYT8UIS/8Pw3s0wwlSw/TAYwgHt9vWN/1v WnpDeL5tdGxT4+tEN+2O3gDtwPP4Kv7n/n8FLlk+UjxfMGi6p2BwV50ZmmHBFUUIxmTGHkKK 4IoUWRwyTLIW9LNIVV6Bv8A5bK0a4Jcz0ShfN7oAtkDf7If3MMefUA5FluAUMxTDEtEU5zm/ CYxAxCfWghjnjOJpwRCEWQwpifHsETBTFWU8uez2vTH8CTmNFGEYxCQKuo7v8Dqv53SHPeVX v+DfHBv+RySb4XlBuSujw46xj//ttv2F/lt8Adb8rwI/y//tVQN5RPGSVa4Djhv0b/p+865c zAuUJORjC+50VRPFtJifhQUjKVerv+dZoRI6/3iqOEPZMHAm/mjovO81784+hEkCZx8QpYTC jFCE55mwdAN3dHPVvw6GjuuNAqE7zbvUWnVy642uA8dTBr7sT1jLKtfdaviO61FPtFq9MnWx 0+1Vf9Dj95RSUBUhauWmrKyMRxP/duIfUtM2/F/p5QG7LrGP/7rZ2fDfaHP+G5Zu1PyvApLE D2EuKRqmkjjgrKkC6HOYLhPUWtENc2pyPhY5ktZ5yrmCcqYsCefqNEGwXkqipCF95NT81Y9X Yw82/Bdyc5wxnpP/dWyx/xumodf5XxXY9f9xcsC98R+P+Xb9b/EEsNb/KvCS878pzmSc5TlD kQTKvUuR38F4NPHcnqhNQ5ypkcJHG+DsfmUED5gtxC4lr9R1m0HX6XZ5i7I+CUWzywInMYRf bm6tbTsRKQLO+FJKEvlw/ELcjzFVFV4GA3/Qv/Qcry/ntD3C0+8gCbdmXVpER95Cd/m/elmH HmMf/21TL/nf1nVx/sMTwJr/VeD89Y8KAMBKAZaUzOnz2c+b/xT9AV6fc3riLEqKGMHbp6zq r626nMWYiCoFZ0wRixuanwiOT5V/+PjLguXQPHm3E/K+Gaxp/kBoEv9xcnqxsZSPyz8ncOu4 753rXjD2vf7NNZyoKzuKWEEz0C6Uf19K5LvLfzVGy/zgUeBz4j+9Lc9/TVOr478qsOv/zbZz yDH26b+lWaX/+QYg4j/DrvW/Erxw/efT9wnIswoxGkM5K08fpIUQ/qdVvS3+a6nWX5BUHwUb /qfWsf4Cfo7+mx1T5P+aXef/NWrUqFGjRo0aR8F/uPExIwAoAAA= --6Mp9riKx/1-- From debbugs-submit-bounces@debbugs.gnu.org Tue Jul 09 19:27:13 2024 Received: (at 71847) by debbugs.gnu.org; 9 Jul 2024 23:27:13 +0000 Received: from localhost ([127.0.0.1]:54280 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sRKEr-0001aj-8e for submit@debbugs.gnu.org; Tue, 09 Jul 2024 19:27:13 -0400 Received: from mail-yb1-f177.google.com ([209.85.219.177]:46184) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sRKEo-0001aS-D3 for 71847@debbugs.gnu.org; Tue, 09 Jul 2024 19:27:11 -0400 Received: by mail-yb1-f177.google.com with SMTP id 3f1490d57ef6-e03c689addcso6006177276.0 for <71847@debbugs.gnu.org>; Tue, 09 Jul 2024 16:27:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1720567558; x=1721172358; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=F5EAOVLiXkPcLafUVgwYGsCIfMXQ1h+1VQ7UWVOQZH0=; b=jabZjoqKBTOex55vAVJOy7iWriXrHmVzvpkGEKqj9Wz2tfNA2OOFULj38ZwAU/euNw o1pmOJhnvpxud2ieNBCYvWNe2n96NFZuR5KjmMWvHTKQXpj/B9UFTu9T5Uw7fDDAkvaB 2tJ6eJO6Q8MuyEt9CDyjR+aHiUwWThM5KkDgrg8E61aq/r+uf8zYml+m6jYRGSL3k1Js dg4ybS0Wg15vwcQ1d3tWWwoKJ5ggKFEylOdFX5d008/3h/i9Wy3ex0GUVvo7X+oYJOmm B/X1rnhUEi+Eo/GwaPDiJMkBp7r+2tPpK0AjdOS/hYyEv6ZPP+UMxHPLFzLZj8Q/WanW qwMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1720567558; x=1721172358; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=F5EAOVLiXkPcLafUVgwYGsCIfMXQ1h+1VQ7UWVOQZH0=; b=aIF7ljAEm7LXOVrPz7cy/7NMOABapt+8yKDwhmqmqZAItkVqvimHB+eG+5lCinxOGp hTkTksEuqJzt57ECN5yc9FK7DEVvRaBLY13m1UHWXH3jpiQEZo3/EkSbuhRlwqRsHEVX rbikMniPjK/ev2LnP6Bh4Y6KvvG2I7FQP9YNMl+j2Z6CY/20r4BpfYZE3rsaFR2+7iRr 9t8unfNPwpBkb3A10v0+6O1nFMPMrq4J1mxvpq2gKxwjV0QEKQoCW2TEmJoe49Xv8p4U tmpSGhbAaFa/7JwbOXHbHsMAmUV6c+ZRllGnhrwE3cE0C7AKi41lyQ57gEBFRoWuZYnm frRg== X-Gm-Message-State: AOJu0YzrnEL6v3eY4o89B87rzMz8LZ9HuNd2jxnUGiVoE1ovGXS5Xhtp uH3W1x68jdO1c8cD2EUbq0RBlm+aO3gRXl8J2H0FB34uN53TRvu86V0Xldmz/xFqmN5QK7OSTtj lokjXFjayp8JopFhsFW55FQ82PBw= X-Google-Smtp-Source: AGHT+IHsb4aUktoT+uHe0r8DKCckhTD+9ypPB0MYLFDNLyBhksTZ6UUOU5umyWLLi8m0m7CETlWfECeLtSkxI+vX4hQ= X-Received: by 2002:a25:f503:0:b0:dfd:b613:cd5f with SMTP id 3f1490d57ef6-e041b07042cmr4703893276.5.1720567558491; Tue, 09 Jul 2024 16:25:58 -0700 (PDT) MIME-Version: 1.0 References: <202407082205.468M5Dm91567149@freefriends.org> In-Reply-To: <202407082205.468M5Dm91567149@freefriends.org> From: Dave Hart Date: Tue, 9 Jul 2024 23:25:47 +0000 Message-ID: Subject: Re: bug#71847: Self-inflicted problem, libtool and automake installed to different prefixes To: Karl Berry Content-Type: multipart/alternative; boundary="00000000000022d43c061cd8da19" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 71847 Cc: 71847@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --00000000000022d43c061cd8da19 Content-Type: text/plain; charset="UTF-8" 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 > @node Libtool library used but LIBTOOL is undefined > > After making a hello,world using libtool (attached for my own memory :), > I found that just running aclocal -I... did not suffice. After the > aclocal run, the next error was: > configure.ac:9: error: required file './ltmain.sh' not found > just as already described in the manual (preceding node). So running > libtoolize is needed, not just playing with -I options, as far as I can > tell. > > I also discovered that although libtoolize only asks you to "consider" > creating an m4/ subdir for macros, in fact it is a requirement, at least > in the case of automake and libtool in different prefixes. Without > AC_CONFIG_MACRO_DIRS([m4]), the original > "error: Libtool library used but 'LIBTOOL' is undefined" persists. > > (Aside: It was also rather irritating to have to run automake > --add-missing three separate times as new pieces were found. Oh well.) > > It's all quite a confusing conglomeration, but I don't think there's > anything to do about here. > > I guess I will leave this open in hopes of figuring out that m4 stub > approach, but this is all I can see to do for the 1.17 release. (I've > got nothing else pending for 1.17, so if anyone knows of a reason to > delay, let me know asap.) --thanks, karl. > This looks great, Karl, thanks for all your time investigating and documenting the issue. Lots of nice nit-fixing too! Cheers, Dave Hart --00000000000022d43c061cd8da19 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On = Mon, 8 Jul 2024 at 22:05, Karl Berry <karl@freefriends.org> 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
=C2=A0 @node Libtool library used but LIBTOOL is undefined

After making a hello,world using libtool (attached for my own memory :), I found that just running aclocal -I... did not suffice.=C2=A0 After the aclocal run, the next error was:
=C2=A0 configure.ac:9: error: required file './ltmain.sh' not found=
just as already described in the manual (preceding node).=C2=A0 So running<= br> libtoolize is needed, not just playing with -I options, as far as I can tel= l.

I also discovered that although libtoolize only asks you to "consider&= quot;
creating an m4/ subdir for macros, in fact it is a requirement, at least in the case of automake and libtool in different prefixes.=C2=A0 Without AC_CONFIG_MACRO_DIRS([m4]), the original
"error: Libtool library used but 'LIBTOOL' is undefined" = persists.

(Aside: It was also rather irritating to have to run automake
--add-missing three separate times as new pieces were found. Oh well.)

It's all quite a confusing conglomeration, but I don't think there&= #39;s
anything to do about here.

I guess I will leave this open in hopes of figuring out that m4 stub
approach, but this is all I can see to do for the 1.17 release.=C2=A0 (I= 9;ve
got nothing else pending for 1.17, so if anyone knows of a reason to
delay, let me know asap.) --thanks, karl.

This looks great, Karl, thanks for all your time = investigating and documenting the issue.=C2=A0 Lots of nice nit-fixing too!=

Che= ers,
Dave Hart
--00000000000022d43c061cd8da19-- From unknown Fri Aug 15 15:33:28 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Wed, 07 Aug 2024 11:24:09 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator