On Sat, Nov 30, 2024 at 12:09:06AM +0000, Gavin Smith wrote:
> On Fri, Nov 29, 2024 at 05:28:58PM +0100, Patrice Dumas wrote:
> > On Thu, Nov 28, 2024 at 11:50:31PM +0100, Patrice Dumas wrote:
> > > I checked on a macos, and the failure happens only with LC_ALL=C. This
> > > is something we already experienced in the past with libintl-perl.
> > >
> > > Both Perl calling gettext and the C only teximakehtml call fail to
> > > translate strings. So it seems to be a failure to switch locale in
> > > tp/Texinfo/XS/main/translations.c translate_string when LC_ALL is C.
> >
> > I had a more in-depth look at what happen on macos-12, and I did not
> > find any lead on what could be wrong.
> >
> > The switch_messages_locale in tp/Texinfo/XS/main/translations.c called
> > from translate_string to set first a non "C" locale manages to switch to
> > en_US.UTF-8, with LANG set to en_US.UTF-8 and LC_MESSAGES set from
> > setlocale to en_US.UTF-8 too. Then LANGUAGE is set to "pt" and gettext
> > is called, but the string is not translated.
>
> The only idea I have at the moment is that it could be some issue with
> threads, if locale switching doesn't work as expected. We had to call
> switch_to_global_locale in the Perl API so that setting the locale
> variables in the environment would work. I see that main/translations.c
> uses this function via 'call_switch_to_global_locale'. Do you
> know if this is succeeding as expected?
In the latest tests I did there is no Perl involved at all, for the test
with debugging I did I report above I used teximakehtml to avoid any
possible confusion with C/Perl interactions. In teximakehtml,
call_switch_to_global_locale is called but it is a function that do
nothing, in main/replace_perl_api_call.c:
void
call_switch_to_global_locale (void)
{
}
> You said earlier that these builds were using Perl 5.40.
>
> There is a mention of locale setting in the changes for Perl 5.38 which
> could be relevant:
>
> https://perldoc.perl.org/perl5380delta
>
> It turns out that some POSIX 2008 platforms have or have had buggy
> implementations, which forced perl to not use them. The ${^SAFE_LOCALES}
> scalar variable contains 0 or 1 to indicate whether or not the
> current platform is considered by perl to have a working thread-safe
> implementation. Some implementations have been fixed already, but
> FreeBSD and Cygwin have been newly discovered to be sufficiently buggy
> that the thread-safe operations are no longer used by perl, starting in
> this release. Hence, ${^SAFE_LOCALES} is now 0 for them. Older versions
> of perl can be configured to avoid these buggy implementations by adding
> the Configure option -DNO_POSIX_2008_LOCALE.
>
> This could explain the failure on Cygwin (although I don't completely
> understand what the issues are with threads). Is there any way to check
> what the value of ${^SAFE_LOCALES} is?
The following should work
perl -e 'print "${^SAFE_LOCALES}\n"'
I will add it to the CI reports, maybe it will lead to something useful,
but I doubt it as there is nothing done with threads in teximakehtml.
--
Pat
