Re: remove intl/ directory?

[Iain Sandoe <idsandoe@googlemail.com>]

Hi Bruno,

> On 18 Jun 2022, at 18:01, Bruno Haible <bruno@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
> 
> 
>