Hi,
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.
* 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
