From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com [IPv6:2a00:1450:4864:20::333]) by sourceware.org (Postfix) with ESMTPS id 087BC3858D32 for ; Sat, 18 Jun 2022 17:42:46 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 087BC3858D32 Received: by mail-wm1-x333.google.com with SMTP id e5so3750909wma.0 for ; Sat, 18 Jun 2022 10:42:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=TLzhzdMv/UG2/DcfCjx2KrT4iFkbKVASSN1LczcYepk=; b=lvBp3WMLSXYVr6a3WWNc4E+WdP4w/GAIYePvSoj7c/3fI2fgr0MXFOmeR4i/hY6ekL m1ELiLoi9U9piUSY0OS8FjO9HbOLNU7HpHF6j63nuThXSjLymZdJ9lC/cl0DFIRMQ8Uf ga6nWQXWcliUJhrgKMEVE0ktW5AHhE1dY5DOg5/aeFH4HuPSW68zZPFBhvmZgyiR4k6s TYnQI89O2GP91n0sqIMAINtV02DLHy2StRFW2/Pj9q0ti+hCHnF0NWAHTF/ktCddrGR/ 2OGA47UHwPhjXXaK4w5lVc7qmFYP8KRZNOQ8OYPxTjFcsCfpolKRUESQvmg03yIxNIvZ hL0w== X-Gm-Message-State: AJIora/Vp41cBQ9qbSEBC2aETrucKzEwCAHj+N9jPf1//OjGFFEjCbob a5wuYESSaI+a/l1i1Fs8JE8= X-Google-Smtp-Source: AGRyM1uP/dXxYc1/xEO/SIelKv/vo51SSIWMXAe5bY729sl6ugVJZuqsLiJF7D4mo7YdYGHl39151w== X-Received: by 2002:a05:600c:1c0e:b0:39e:f120:c216 with SMTP id j14-20020a05600c1c0e00b0039ef120c216mr6595092wms.163.1655574164445; Sat, 18 Jun 2022 10:42:44 -0700 (PDT) Received: from [192.168.1.95] (host81-138-1-83.in-addr.btopenworld.com. [81.138.1.83]) by smtp.googlemail.com with ESMTPSA id p12-20020a5d4e0c000000b0020fe86d340fsm8065283wrt.55.2022.06.18.10.42.43 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 18 Jun 2022 10:42:43 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) Subject: Re: remove intl/ directory? From: Iain Sandoe In-Reply-To: <32334822.2dzg3u6YtW@omega> Date: Sat, 18 Jun 2022 18:42:42 +0100 Cc: GCC Development Content-Transfer-Encoding: quoted-printable Message-Id: <2F423461-3AF4-4BA9-95D8-EC53B49B43A2@googlemail.com> References: <32334822.2dzg3u6YtW@omega> To: Bruno Haible X-Mailer: Apple Mail (2.3608.120.23.2.7) X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gcc@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jun 2022 17:42:47 -0000 Hi Bruno, > On 18 Jun 2022, at 18:01, Bruno Haible wrote: > As the long-term GNU gettext maintainer, I would suggest to remove the = intl/ > directory from the GCC distribution. >=20 > The effect for the users would be: > * On systems without glibc, users who want an internationalized GCC > installation would have to install GNU gettext first. Then the GCC > binaries would be linked with the shared library libintl.so > (unless gettext was built with --disable-shared); they would no = longer > contain the libintl code in 'cc1', 'cc1plus', etc. As a maintainer for GCC on a non-glibc system, I would: (a) welcome a more modern version of intl, wih the bug-fixes etc. (b) not want to [force] add a shared lib dependency for my downstream. - so, please could we follow the pattern for GMP et. al. where the = library can be provided with =E2=80=94with-intl=3D pointing to an installation, = or be built in- tree by symlinking an approved version into the GCC tree. For such [non-glibs] systems where these libraries are not = =E2=80=99normally=E2=80=99 installed, it is still very much preferable to be able to statically = link them so that a compiler can be distributed with no deps other than those provided by the OS (and we can test what we ship and ship what we test). thanks, Iain > * On systems with glibc, no change. >=20 > The effect for the GCC maintainers would be: > * Easier to stay up-to-date with upstream libintl. > * Less maintenance work with *.m4 files such as > codeset.m4 > glibc21.m4 > intdiv0.m4 > inttypes_h.m4 > inttypes.m4 > inttypes-pri.m4 > lcmessage.m4 > stdint_h.m4 > uintmax_t.m4 > ulonglong.m4 > * Reduced risk of a CVE that would impact GCC binaries. >=20 > Rationale: > * This intl/ code is from 2003; of course several bugs have been > fixed in it over the last 19 years. > * At that time GNU packages were still favouring static libraries. > GNU libtool became widely reliable only about in 2005. > * Since then, distros have been favouring shared libraries over > static libraries, in order to be able to fix CVEs without > rebuilding many dependent binaries. > * For this reason, GNU gettext removed the support for this way > of packaging libintl in version 0.20 (May 2019). The NEWS entry > said: > - The --intl option of the gettextize program (deprecated since = 2010) is > no longer available. Instead of including the intl sources in = your > package, we suggest making the libintl library an optional = prerequisite > of your package. This will simplify the build system of your = package. > - Accordingly, the Autoconf macro AM_GNU_GETTEXT_INTL_SUBDIR is = gone > as well. >=20 > This point came up while discussing with Eric Gallager, who is working = on > the GCC configury. >=20 > I don't volunteer to implement this suggestion, but I can give advice = where > needed. >=20 > Bruno >=20 >=20 >=20