Re: Problem with gettext on Solaris

[Brian Cameron]

Bruno:

Sorry that it has taken me so long to respond to your last email (sent
last August), but we're finally starting to move forward in figuring
out how to best fix it so AM_GNU_GETTEXT on Solaris.

Looking at the way AM_GNU_GETTEXT is defined it seems to check if a few
internal symbols such as,_nl_msg_cat_cntr, _nl_domain_bindings, and
_nl_expand_alias to find out whether GNU gettext is being supported in
the system or not and also what revision is supported by the system.
This does not seem very portable.

I wonder why the AM_GNU_GETTEXT macro does not check the
__GNU_GETTEXT_SUPPORTED_REVISION macro to see what version the
system supports rather than checking internal symbols that may
not be the same on each system (such as the _nl* functions).

I believe Solaris currently supports Revision 0 correctly.  Does the
AM_GNU_GETTEXT macro have a hard dependency on revision 1 or can it
also work with revision 0?  If it works (or can be made to work) with
revision 0, then perhaps we could improve things by simply getting the
Solaris gettext() people to make sure that we define
__GNU_GETTEXT_SUPPORTED_REVISION(0).  We currently do not do this.

Is this correct?  If so, what would be the best way to approach getting
this issue resolved in AM_GNU_GETTEXT?  Is there a bug reporting tool
I should use to file a bug, or is this mail list the right place to
report such issues?

Currently Solaris doesn't support the __GNU_GETTEXT_SUPPORTED_REVISION
at all, and I'm working with the Sun gettext() people to get this
macro defined so it says that Sun supports revision 0.  We are still
trying to determine if supporting revision 1 would be a big benefit
to Sun users.  So any feedback about what breaks if we only support
revision 0 would be useful.

Brian


> Brian Cameron wrote:
> > The AM_GNU_GETTEXT macro fails on Solaris even though Solaris has been made
> > compatible with GNU gettext.  AM_GNU_GETTEXT always wants to build the
> > gettext sources included with various modules.  So at Sun, we have been
> > working around this by using AM_GLIB_GNU_GETTEXT which has a special test
> > for Solaris making things work.  It would probably be better if this could
> > also be fixed in AM_GNU_GETTEXT.
>
> Thanks for reporting this. Solaris' libc functions indeed can use GNU .mo
> files as they were in 2000/2001, i.e. major revision 0. In 2002, the
> GNU .mo file format has been augmented (in major revision 1) to support
> <inttypes.h> placeholder strings. This file format is not supported by
> Solaris, as far as I know. For optimal results, the AM_GNU_GETTEXT
> macro therefore continues to use the GNU code, also on Solaris.
>
> > AM_GLIB_GNU_GETTEXT has the following special test-case to recognize
> > that allows it to work:
> >
> >            AC_TRY_LINK(, [extern int _nl_msg_cat_cntr;
> >                           return _nl_msg_cat_cntr],
> >              [CATOBJEXT=.gmo
> >               DATADIRNAME=share],
> >              [case $host in
> >              *-*-solaris*)
> >              dnl On Solaris, if bind_textdomain_codeset is in libc,
> >              dnl GNU format message catalog is always supported,
> >              dnl since both are added to the libc all together.
> >              dnl Hence, we'd like to go with DATADIRNAME=share and
> >              dnl and CATOBJEXT=.gmo in this case.
> >              AC_CHECK_FUNC(bind_textdomain_codeset,
> >                [CATOBJEXT=.gmo
> >                 DATADIRNAME=share],
> >                [CATOBJEXT=.mo
> >                 DATADIRNAME=lib])
>
> This macro code is woefully out of date. GNU gettext does not support
> installation of .mo files under $PREFIX/lib since 0.10.36.
>
> > Would it be possible to get similar logic included in the AM_GNU_GETTEXT
> > macro?
>
> Only if Solaris implements the <inttypes.h> placeholder strings, and
> defines __GNU_GETTEXT_SUPPORTED_REVISION(major) in <libintl.h> in a way
> that signals that major revision 1 is also supported.
>
> Bruno
>
> From - Mon