in reply to Re: Building Perl 5.28.0 on OpenBSD 6.4 -current
in thread Building Perl 5.28.0 on OpenBSD 6.4 -current

Thank you bliako,

Printing on lines 482 and 491, I got:

invalid_string is 'LC_COLLATE=foo_BAR;LC_CTYPE=foo_BAR;LC_MESSAGES=foo_BAR;LC_MONETARY=foo_BAR;LC_NUMERIC=foo_BAR'
valid_string is 'LC_COLLATE=C.UTF-8;LC_CTYPE=C.UTF-8;LC_MESSAGES=C.UTF-8;LC_MONETARY=C.UTF-8;LC_NUMERIC=C.UTF-8'

and
echo $LC_ALL

[download]
printed nothing.

I will investigate further.
Thanks again.

Replies are listed 'Best First'.
Re^3: Building Perl 5.28.0 on OpenBSD 6.4 -current
by syphilis (Archbishop) on Nov 11, 2018 at 02:45 UTC
    I will investigate further.

    There's a bug report just created about this at:
    https://rt.perl.org/Ticket/Display.html?id=133649

    It suggests that the test failure can be avoided by building a threaded perl.
    (Of course, there's no implication that such an avoidance should be regarded as a solution.)

    I suggest that you follow that bug report - or even contribute to it if you've discovered something that might be useful.

    Cheers,
    Rob
[reply]
      Starting in 5.28 on POSIX machines, perl uses completely different underlying locale manipulation library routines on threaded builds than on unthreaded.

      POSIX 2008 introduced completely new functions to support thread-safe locale handling, and under threads, perl now uses them so that locale handling is now thread-safe. For example, on a threaded build, uselocale() is used instead of setlocale(). It was a lot of work to make this transparent to the calling code. And this ticket is a case where it isn't transparent. I made the decision to retain the old functions for non-threaded builds, as a precaution against the newfangled ones being buggy.

      It appears at first glance, that this is an instance where a new netbsd release broke setlocale() but not uselocale(). You could get around the problem, as someone mentioned, by using threaded, or you could hack perl.h to define USE_POSIX_2008_LOCALE on an unthreaded build, and recompile. I added a mechanism in 5.28 to allow you to specify at compile time an option to avoid the new functions, but it never occurred to me that one would want to use them over the old tried and true ones. I can add that in 5.30.

      I recall a locale handling bug in one of the bsd forks that got fixed as a result of perl's complaining. You might grep their bug tracker to see if something has been reported to the OS.

      Now that we can reproduce it, I'll debug it and follow up

      P.S. This is a case where Windows does a better job IMO than POSIX in allowing thread-safe locales. They created a metafunction that toggles setlocale() from being thread-specific vs global. This method has been criticized, but it allows a one line change to most programs to convert them into thread-safe, instead of having to do a major restructure, which POSIX left us with.

[reply]
        I forgot to mention, that the Windows method predates the POSIX one by several years
[reply]

In Section Seekers of Perl Wisdom