From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout-p-201.mailbox.org (mout-p-201.mailbox.org [80.241.56.171]) by sourceware.org (Postfix) with ESMTPS id EDDE73858404; Tue, 26 Sep 2023 15:25:24 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org EDDE73858404 Authentication-Results: sourceware.org; dmarc=pass (p=reject dis=none) header.from=aarsen.me Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=aarsen.me Received: from smtp202.mailbox.org (smtp202.mailbox.org [10.196.197.202]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-201.mailbox.org (Postfix) with ESMTPS id 4Rw3TZ1sc4z9spD; Tue, 26 Sep 2023 17:25:22 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aarsen.me; s=MBO0001; t=1695741922; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=LE8UXqTLc96n4Yi5pCCzceEeWK4p8L3d5BZSZv4tI8Y=; b=Myva1ZBw8upJfbQICasnLDCa1mxYZd0nSdakH+ZJPDZlJvQjovT+03J6OqncHRl7w4uNRF l3qSg/4k36Ekxn6dh23OCRue2mpJkHLl8tCZZkPcf/0Qyd9vs0K2hWlwQrtL2m1vTjPDHY r6cQpsjxOE/idBTgtN7GuHW9Gzj130FD9X71wQcUCOiUi4GhlfBYop2QR43XiqtvYWr1lm DFU14NacbF8hJZDWYKZJdjDf6l0zT+Z/nHqXAwcShK/UcTxwa5YBBR/KVV9JZFjqxZUgXZ riBX6YqqmAj0t7nqKsOKDJkcwuu5w7wNQyRH1MEqUjWGHrGaZG996mvfUMzOdQ== References: <20230926004300.1716711-2-arsen@aarsen.me> <20230926004300.1716711-3-arsen@aarsen.me> <1c90c3ea-0b54-520c-8524-7feb6b88212e@suse.com> From: Arsen =?utf-8?Q?Arsenovi=C4=87?= To: Jan Beulich Cc: Bruno Haible , Iain Sandoe , gdb-patches@sourceware.org, binutils@sourceware.org Subject: Re: [PATCH v2 1/2] *: add modern gettext support Date: Tue, 26 Sep 2023 16:44:48 +0200 In-reply-to: <1c90c3ea-0b54-520c-8524-7feb6b88212e@suse.com> Message-ID: <864jjhrm73.fsf@aarsen.me> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" X-Spam-Status: No, score=-5.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,KAM_INFOUSMEBIZ,RCVD_IN_DNSWL_LOW,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, Jan Beulich writes: > May I please ask that a change like this come with a real description? The > ChangeLog entries certainly describe - purely mechanically - what is done > to the files, but to be honest I cannot really read out of the (large) > patch what the overall behavioral change is. Hopefully, none. Building without gettext in-tree or on the system should result in a working build with no localization, with gettext in-tree and on the system it should result in the usage of the system gettext, with gettext on the tree but _not_ on the system, it should result in a new (static) copy being built and linked into the tools, with working localization, and with no gettext in tree but in system (either in libc or in libintl) should result in a localized build using the system gettext facilities. The behavior for the in-tree but also on the system case (e.g. building with gettext in-tree on a GNU system) can be overridden with =2D-with-included-gettext (which is a configure flag for gettext-runtime, and was a configure flag for intl/ before that). I've updated the commit message to add: > This patch updates gettext.m4 and related .m4 files and adds > gettext-runtime as a gmp/mpfr/... style host library, allowing newer > libintl to be used. >=20 > This patch /does not/ add build-time tools required for > internationalizing (msgfmt et al), instead, it just updates the > runtime library. The result should be a distribution that acts > exactly the same when a copy of gettext is present, and disables > internationalization otherwise. >=20 > There should be no changes in behavior when gettext is included > in-tree. When gettext is not included in tree, nor available on the > system, the programs will be built without localization. I hope this clarifies it. Would you like to see anything else in the description? Apologies for not adding context initially, I've been finishing this patch on-and-off for a long time (due to being quite busy), and so, what context is and isn't present (and what is and isn't known) got lost on me. Jan Beulich writes: > I'm therefore only getting the impression that you make gettext > 0.22(?) a prereq to building binutils and gdb. No, it's still optional. 0.22 is only a prerequisite for building in-tree, otherwise, quite old versions of gettext from the system should work, too. > Which in turn may make it impossible to (easily) build either on older > systems (it would certainly limit [remove?] my ability to test 32-bit > builds of binutils, as the newer distros I use all only come in 64-bit > flavors; there may be ways to configure as 32-bit, but past experience > has shown that such is potentially fragile / only partially > functioning). A localized build should work fine on a 32-bit system (ISTR Iain testing 32-bit targets by dropping a copy of gettext in-tree, but don't quote me on that). A build of binutils or gdb (or gcc, for that matter) which has a gettext/ tree included in the toplevel should behave as it does today. In any case, non-localized builds should always work. =2D-=20 Arsen Arsenovi=C4=87 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iOYEARYKAI4WIQT+4rPRE/wAoxYtYGFSwpQwHqLEkwUCZRL34F8UgAAAAAAuAChp c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0RkVF MkIzRDExM0ZDMDBBMzE2MkQ2MDYxNTJDMjk0MzAxRUEyQzQ5MxAcYXJzZW5AYWFy c2VuLm1lAAoJEFLClDAeosSTQioBAI5gB/6MDbHmAeV/lOgk3zwtFgjWPqUIp85d rYmi0eNTAQDW/AFCwUC/RakaLSpnlDXrNs2IUo4gS7UfcIrUwZFZBQ== =f9b/ -----END PGP SIGNATURE----- --=-=-=--