On Sat, Jun 18, 2022 at 1:44 PM Iain Sandoe via Gcc <gcc@gcc.gnu.org> wrote: > > Hi Bruno, > > > On 18 Jun 2022, at 18:01, Bruno Haible <br...@clisp.org> 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 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, 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 library > can be provided with —with-intl= 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 ’normally’ > 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 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. > > > > 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 where > > needed. > > > > Bruno > > > > > > >
