From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Bruno Haible Newsgroups: gmane.lisp.guile.devel Subject: Re: what to do about gnulib Date: Mon, 24 Jun 2024 19:09:11 +0200 Message-ID: <7037800.QWXsJ6tzlI@nimes> References: <87ed8m8k6r.fsf@pobox.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="nextPart11771975.qOBuL9xsDt" Content-Transfer-Encoding: 7Bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="39535"; mail-complaints-to="usenet@ciao.gmane.io" To: guile-devel@gnu.org, Andy Wingo Original-X-From: guile-devel-bounces+guile-devel=m.gmane-mx.org@gnu.org Mon Jun 24 19:09:52 2024 Return-path: Envelope-to: guile-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1sLnCR-000A2D-Lh for guile-devel@m.gmane-mx.org; Mon, 24 Jun 2024 19:09:51 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sLnC5-0006lW-4K; Mon, 24 Jun 2024 13:09:29 -0400 Original-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 1sLnC0-0006kz-M0 for guile-devel@gnu.org; Mon, 24 Jun 2024 13:09:24 -0400 Original-Received: from mo4-p00-ob.smtp.rzone.de ([81.169.146.218]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sLnBx-00035s-25 for guile-devel@gnu.org; Mon, 24 Jun 2024 13:09:23 -0400 ARC-Seal: i=1; a=rsa-sha256; t=1719248952; cv=none; d=strato.com; s=strato-dkim-0002; b=A8BsR8s0OONdMm+q7nC2oAR8XKdPuQb4Rrr7aO8kQxgi0a3zCCURJiVIkSsR7G1ylU BhHcGRZuAcy6L3x6OptlDr+4jiEIO0mKfRZgGvCmE0BqvhzRuiGOhpU2YS9Rlp9KHWKG 4W4WZ1XMsnHtSI3plGXJnBFTPomjYLZlfCFnV6g+JtTmdeTm3cWgFaf1qlFutqZhUFqZ jcZJzq5QyL7ty9glD5lA939ccNqjgJEKKJIEUwJWuT5wmcosHo4S+2lW/z8h91HeZa7I l3SOeAo5DEDD7k2TDx5olXMhHdGw6ha0J7urd+fX2PEALPsMoBRZl4M/Mpw8Zrvhil9W k0Lw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; t=1719248952; s=strato-dkim-0002; d=strato.com; h=References:In-Reply-To:Message-ID:Date:Subject:To:From:Cc:Date:From: Subject:Sender; bh=Q/n9K/PTgyi94pkqMOsUybw2b9Ftn1RTLajeMY+i2yw=; b=iH2u3LDnuWbEEAwNKD87Sbu2GKsMYO2Zt2liObSnNMbIa1wMfRh+AzPofLfGcXhtaU wq36HHBXn/hYDKREfK/2eGi2y6MAnskiTR0V0Qi9otu/se6w+UVTpSJSz2KwYIMf3X3T t1SUjuWunvAUu83X+rySfqswxKTDb+H5ecR9rx3F/WirA3YlaW0EGqk3hTNSQKrBd/kf XtIOnTVUkFNLvfUJB79DgIxNmJ96+xr79eqyFXinMr4A59O3NA4u/SZSwlToDkpToV7o 8Kid7vjxrabIpsEEsNdNb3UnL3EejIZnaVmOxBrHaH1VnZWCUd9cfiVwcOHYBIVP4mnq hunQ== ARC-Authentication-Results: i=1; strato.com; arc=none; dkim=none X-RZG-CLASS-ID: mo00 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1719248952; s=strato-dkim-0002; d=clisp.org; h=References:In-Reply-To:Message-ID:Date:Subject:To:From:Cc:Date:From: Subject:Sender; bh=Q/n9K/PTgyi94pkqMOsUybw2b9Ftn1RTLajeMY+i2yw=; b=laOXpSg74rNrDAnkV5xiSQjakNjqTP6TgxTrQVJfJCun3eAXp33f5P5b/VVoucA2Sm yOJq6W7pzKsJZO0Er0wRgt6McjutoOE/k8227tpQYzNSHrEbrrL2OXsP0UcjPBrUbqKu 6krEX6PWeA7KvunCNdlnOzSTe8EkxWqZOs4J82nObiJbj17ZgCA5Sub8Jz0rUiQ9xNeJ uTV7MhQ3Luq6w6viF8qkigQ9gwr+i4J+2X8LwuHhCPnuQb1poe9gawRyn6gx98hb4cxL Png87jEOQzNCBtLosoddEvfpqO/vgP86P7z3fN6+5kf5Tvf91vagydQTiPrUi189vt63 DU8A== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; t=1719248952; s=strato-dkim-0003; d=clisp.org; h=References:In-Reply-To:Message-ID:Date:Subject:To:From:Cc:Date:From: Subject:Sender; bh=Q/n9K/PTgyi94pkqMOsUybw2b9Ftn1RTLajeMY+i2yw=; b=1Z6gL4aqHDIYUcwNJGh471liHwn7vJH4AHooj3GSAPz2NS8TtKx/B1jaiQA/4Jqzbf OltTzLpXPTTsy3VMmdAw== X-RZG-AUTH: ":Ln4Re0+Ic/6oZXR1YgKryK8brlshOcZlIWs+iCP5vnk6shH0WWb0LN8XZoH94zq68+3cfpOR2KNXfuFi6TuDM+MHa7T9MWdKfA==" Original-Received: from nimes.localnet by smtp.strato.de (RZmta 50.5.0 AUTH) with ESMTPSA id N0957e05OH9BX6Q (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits)) (Client did not present a certificate); Mon, 24 Jun 2024 19:09:11 +0200 (CEST) In-Reply-To: <87ed8m8k6r.fsf@pobox.com> Received-SPF: none client-ip=81.169.146.218; envelope-from=bruno@clisp.org; helo=mo4-p00-ob.smtp.rzone.de X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 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, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_NONE=0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane-mx.org@gnu.org Original-Sender: guile-devel-bounces+guile-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.lisp.guile.devel:22468 Archived-At: This is a multi-part message in MIME format. --nextPart11771975.qOBuL9xsDt Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" Hi Andy, Thanks for CCing me. You could equally well have CCed bug-gnulib; that works too. > To recap, gnulib provides compile-time shims for "foreign" or > out-of-date target systems that allows Guile to program to a single > POSIX + GNU API and not worry too much about what the system actually > offers. Gnulib also has other functionality than portability. There is also - build / maintenance infrastructure (which Guile makes use of), - other functionality [1]. > However I was unable to update gnulib before the most > recent release. The reason is essentially the problem described in this > issue: >=20 > https://sourceware.org/bugzilla/show_bug.cgi?id=3D30051 >=20 > To wit, running "autoreconf -vif" invokes the "autopoint" tool supplied > by installed gettext, which copies over .m4 files from installed > gettext, but these files are older than the ones that are already > "vendored" in-tree by gnulib. Other parts of gnulib depend on the newer > gnulib-supplied macros which were stompled over; autoconf thus fails to > run. I can reproduce a problem by 0. using a git checkout of guile ('main' branch, not 'master' branch), 1. using a GNU gettext version 0.22.5, 0.21, 0.20.2, or 0.19.8.1, 2. removing the gnulib-local/m4/clock_time.m4.diff file, which no longer applies, 3. running $ $GNULIB_SRCDIR/gnulib-tool --update 4. running $ ./autogen.sh (which is what the HACKING file recommends). It fails with configure:12833: error: possibly undefined macro: gl_PTHREADLIB If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. configure:12943: error: possibly undefined macro: gl_WEAK_SYMBOLS configure:27584: error: possibly undefined macro: gl_TYPE_WINT_T_PREREQ autoreconf: error: /usr/bin/autoconf failed with exit status: 1 =46ollowing your analysis, I locally apply the workaround from the Gnulib documentation section "3.11 Caveat: gettextize and autopoint users", redo steps 3 and 4, and the './configure' succeeds, and 'make' succeeds up to the point where it encounters a compilation error: CC libguile_3.0_la-jit.lo jit.c:373:30: error: macro "unreachable" passed 1 arguments, but takes just= 0 373 | unreachable (scm_jit_state *j) | ^ Explanation: 'unreachable' is, per ISO C 23 =A7 7.21.1, a macro that takes 0 arguments. The newer Gnulib makes it available even if the compiler does not yet make it available. Proposed patch attached. > 1. Some projects (e.g. poke) seem to import the whole of gnulib as a > git submodule, and then run "gnulib-tool --update" from that > submodule as part of their bootstrap. In this way the stompled > files are restored. However I do not want git submodules in Guile; > they add additional steps for every time you change to a different > HEAD, and I know from experience that I can't rely on myself to > perform them all, much less any user with a bug report. Do not > want. The way Guile handles versioning of Gnulib-imported files is fine. It corresponds to the "middle road" approach, described in the Gnulib manual [= 2], section "3.13 Integration with Version Control Systems". It is thus supported by Gnulib. > ** Note, for (1) and (2), if you wanted to preserve the ability to > bootstrap from a tarball, you'd have to include gnulib in the > tarball. Of course you could argue that if you are not gnulib-tool > --update'ing, are you really bootstrapping? I don't know the > answer. *** Simon Josefsson is working with the Debian people on this approach. [3] > 3. Fix autopoint to not overwrite newer m4 files with its copies. I > don't know? This is done through the attached patch. > 4. Fix installed gettext to not define gl_ macros ? That would make > it so that it won't stomple on a local gnulib copy. I don't know > though. >=20 > 5. Update to whatever version of gnulib is the latest without this > change? >=20 > 6. Something else? Given that the attached patch works, you don't need to consider these other approaches. Note, though, that the imported po/ infrastructure will still be from 2010, due to this line in configure.ac: AM_GNU_GETTEXT_VERSION([0.18.1]) It would be reasonable to bump this version specification to AM_GNU_GETTEXT_VERSION([0.19.8.1]) (from 2016) or AM_GNU_GETTEXT_VERSION([0.20.2]) (from 2020) or AM_GNU_GETTEXT_VERSION([0.21.1]) (from 2022). Note also that when upgrading to a newer Gnulib, you now have another choice than Gnulib's 'master' branch: the 'stable-202401' branch. See the Gnulib documentation [2], section "1.6.1 Stable Branches". Bruno [1] https://lists.gnu.org/archive/html/bug-standards/2024-05/msg00013.html [2] https://www.gnu.org/software/gnulib/manual/html_node/index.html [3] https://lists.gnu.org/archive/html/bug-gnulib/2024-05/msg00124.html --nextPart11771975.qOBuL9xsDt Content-Disposition: attachment; filename="0001-Fix-conflict-between-Gnulib-and-gettext-s-autopoint-.patch" Content-Transfer-Encoding: 7Bit Content-Type: text/x-patch; charset="UTF-8"; name="0001-Fix-conflict-between-Gnulib-and-gettext-s-autopoint-.patch" >From f67b9b9953827dd23b1f71855d057323530bed98 Mon Sep 17 00:00:00 2001 From: Bruno Haible Date: Mon, 24 Jun 2024 18:53:06 +0200 Subject: [PATCH] Fix conflict between Gnulib and gettext's autopoint program. * autogen.sh: Arrange to not invoke autopoint. --- autogen.sh | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/autogen.sh b/autogen.sh index 2e39fb5d8..f9ece0f24 100755 --- a/autogen.sh +++ b/autogen.sh @@ -33,6 +33,11 @@ echo "" ###################################################################### ### update infrastructure +# Avoid running GNU gettext's autopoint program at this stage, because +# it would overwrite some *.m4 files from Gnulib. See the Gnulib manual +# +# section "Caveat: gettextize and autopoint users". +AUTOPOINT=true \ autoreconf -i --force --verbose echo "Now run configure and make." -- 2.34.1 --nextPart11771975.qOBuL9xsDt--