remove intl/ directory?

[Bruno Haible <bruno@clisp.org>]

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