Re: remove intl/ directory?

[David Edelsohn <dje.gcc@gmail.com>]

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 <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, 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
> >
> >
> >
>