public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Bruno Haible <bruno@clisp.org>
To: Iain Sandoe <idsandoe@googlemail.com>
Cc: GCC Development <gcc@gcc.gnu.org>
Subject: Re: remove intl/ directory?
Date: Sun, 19 Jun 2022 02:32:19 +0200	[thread overview]
Message-ID: <4169891.DDXKiFAisr@omega> (raw)
In-Reply-To: <2F423461-3AF4-4BA9-95D8-EC53B49B43A2@googlemail.com>

Iain Sandoe wrote:
> 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.

That's why we make releases of GNU gettext. The newest release is 0.21.
Find below the list of improvements in libintl that will be relevant to GCC.

>  (b) not want to [force] add a shared lib dependency for my downstream.

In order to avoid shared libs, the user merely has to pass the option
'--disable-shared' to GNU gettext's configure.

> - so, please could we follow the pattern for GMP et. al. where the library
> can be provided with —with-intl= pointing to an installation

That convention is already built-in in the gettext.m4 macro; the option is
called --with-libintl-prefix there.

> , or be built in-tree by symlinking an approved version into the GCC tree.

If you are referring to the sentence found in the GCC documentation for
ISL, MPFR, etc.
  "If an isl source distribution is found in a subdirectory of your GCC
   sources named isl, it will be built together with GCC."
I believe that this can be achieved easily by adding a few lines to the
Makefile.def, such as:

host_modules= { module= gettext-runtime; no_install=true;
                extra_configure_flags='--disable-shared';
                lib_path=intl/.libs; };

The symlink 'gettext-runtime' will need to point to the 'gettext-runtime'
*subdirectory* of an unpacked GNU gettext tarball.

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

OK. If that's your preference, just pass the option '--disable-shared'
to the gettext-runtime/configure script (like shown above).

Bruno

==== Fixes in the libintl library for non-glibc systems, since 2003: ====

Version 0.20.2 - April 2020

* The interpretation of the language preferences on macOS has been improved,
  especially in the case where a system locale does not exist for the
  combination of the selected primary language and the selected territory.

* Fixed a multithread-safety bug on Cygwin and native Windows.

Version 0.20 - April 2019

* The interpretation of the language preferences on macOS has been fixed.

* Per-thread locales are now also supported on Solaris 11.4.

* The replacements for the printf()/fprintf()/... functions that are
  provided through <libintl.h> on native Windows and NetBSD are now POSIX
  compliant.  There is no conflict any more between these replacements
  and other possible replacements provided by gnulib or mingw.

Version 0.18.3 - July 2013

* On Mac OS X systems, the setlocale() function now properly
  invalidates loaded message catalogs when a locale has been set.

Version 0.18 - May 2010

* On MacOS X and Windows systems, <libintl.h> now extends setlocale() and
  newlocale() so that their determination of the default locale considers
  the choice the user has made in the system control panels.

* On MacOS X systems, the gettext()/dgettext()/... functions now respect the
  locale of the current thread, if a thread-specific locale has been set.
\f
Version 0.14.4 - April 2005

* Fix improved detection of the locale on MacOS X.
\f
Version 0.14.2 - January 2005

* Improved detection of the locale on MacOS X.
\f
Version 0.13 - November 2003

* On those few platforms (NetBSD and Woe32) for which the native
  printf()/fprintf()/... functions don't support POSIX/XSI format strings
  with positions, replacements are provided through <libintl.h>.





  parent reply	other threads:[~2022-06-19  0:32 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-18 17:01 Bruno Haible
2022-06-18 17:42 ` Iain Sandoe
2022-06-18 18:14   ` David Edelsohn
2022-06-19  0:53     ` Bruno Haible
2022-06-19  0:32   ` Bruno Haible [this message]
2022-06-19  8:40     ` Iain Sandoe
2022-06-19 20:15       ` Iain Sandoe
2022-06-21  2:05         ` Bruno Haible
2022-06-22 20:21           ` Iain Sandoe
2022-06-23  4:24             ` Bruno Haible
2022-06-23  6:51               ` Iain Sandoe
2022-06-23 15:40                 ` Iain Sandoe
2022-06-23 15:50                   ` Iain Sandoe
2022-06-23 15:13               ` Eric Gallager
2022-06-20 19:45 ` Eric Gallager
2022-06-21  2:09   ` Bruno Haible

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4169891.DDXKiFAisr@omega \
    --to=bruno@clisp.org \
    --cc=gcc@gcc.gnu.org \
    --cc=idsandoe@googlemail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).