in reply to Building Perl 5.28.0 on OpenBSD 6.4 -current

I suggest you start by editing lines 482 and 491 of t/run/locale.t to print out $valid_string and $invalid_string, like so:

is ($?, 0, "In setting complicated valid LC_ALL, final individ categor
+y doesn't need a \';'. valid_string is '$valid_string'");

[download]

That last test (the one which fails, in line 491) is skipped only if your current locale is neither C nor POSIX (see line 70). So it is also worth printing out from the shell your current locale, just to be sure what you have:

echo $LC_ALL

[download]

btw, exporting shell variables can be achieved by the shorter:

export LC_ALL=C

[download]

And once you are there, print all the locales the test script found around line 24 (e.g. print join(",", @locales)."\n";)

Edit: the source of the locale.t is here

Replies are listed 'Best First'.
Re^2: Building Perl 5.28.0 on OpenBSD 6.4 -current
by fishy (Friar) on Nov 05, 2018 at 19:33 UTC
    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.
[reply]
[d/l]
[select]
      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]

In Section Seekers of Perl Wisdom