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, 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 —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). 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 > > >
