From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-vs1-xe32.google.com (mail-vs1-xe32.google.com [IPv6:2607:f8b0:4864:20::e32]) by sourceware.org (Postfix) with ESMTPS id 743D8385828A for ; Sat, 18 Jun 2022 18:14:22 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 743D8385828A Received: by mail-vs1-xe32.google.com with SMTP id g6so6929116vsb.2 for ; Sat, 18 Jun 2022 11:14:22 -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:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=uqyYlhBdBkQhYZUkZ4dLw1ry+pEJcrDPiVRGyO1LGCU=; b=T1kvfYQmx9BCv1PQqnqikOI396eQunzrQeEg0vjhujflt5rrQGEsW0xAlHNSX4trMz qRyDY3PHtnU9MoaVEclVyzWaChmVEOjOrlqcMvXqamlCR65P16sYC9jLLw7GbtgKisqw uLdxrUuA9Jg/Nx6h9ISUizcdGlnG2aPRLrQjLUqxezPFcL3/0MFBO564dyUq+eO2fdrH wXU08+PhoQ8G5QwDgSU6rrHhf5E1N3/RVI/84fSp8oITMk66yiCJ6i7kiFMQf/+EsegQ qjWq+uQKd0v6trupfOV9Z0eTRLOI+6oJKnYS2Q46bPld19pdffyKKxzSBzrTdceh4+H7 Br/w== X-Gm-Message-State: AJIora+2afBl8nFmPwcb3eQIPUQIu/iJLNgRlEY+ZBkLTFwkHhZIZlvS cdjVNyh+ixkQ2YF09z7ZuNcIL1RRmKBPIF4v9c0= X-Google-Smtp-Source: AGRyM1tuEpScH5itq8LCNVrcSO2FqZsJlMm9CQzTZPmCy5nBatMnlOuPdwuEl8DbI/oahe8zeHEG7BT3iMRFiLJVAJM= X-Received: by 2002:a05:6102:c10:b0:34c:1b15:cecb with SMTP id x16-20020a0561020c1000b0034c1b15cecbmr7756092vss.67.1655576061792; Sat, 18 Jun 2022 11:14:21 -0700 (PDT) MIME-Version: 1.0 References: <32334822.2dzg3u6YtW@omega> <2F423461-3AF4-4BA9-95D8-EC53B49B43A2@googlemail.com> In-Reply-To: <2F423461-3AF4-4BA9-95D8-EC53B49B43A2@googlemail.com> From: David Edelsohn Date: Sat, 18 Jun 2022 14:14:10 -0400 Message-ID: Subject: Re: remove intl/ directory? To: Iain Sandoe , Bruno Haible Cc: GCC Development Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.4 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 18:14:24 -0000 On Sat, Jun 18, 2022 at 1:44 PM Iain Sandoe via Gcc wrote= : > > 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. > > > > 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 long= er > > 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, with 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 librar= y > can be provided with =E2=80=94with-intl=3D pointing to an installation, o= r 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=99norma= lly=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). As another maintainer for GCC of a non-GLIBC system, I echo Iain's request. The broad list of systems supported by GCC requires effort, but is one of its advantages. Making it more difficult to support GCC on non-GLIBC systems will be detrimental to GCC. Thanks, David > > thanks, > Iain > > > > * On systems with glibc, no change. > > > > 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. > > > > 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 prerequ= isite > > of your package. This will simplify the build system of your packa= ge. > > - Accordingly, the Autoconf macro AM_GNU_GETTEXT_INTL_SUBDIR is gone > > as well. > > > > This point came up while discussing with Eric Gallager, who is working = on > > the GCC configury. > > > > I don't volunteer to implement this suggestion, but I can give advice w= here > > needed. > > > > Bruno > > > > > > >