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.
In reply to Re^4: Building Perl 5.28.0 on OpenBSD 6.4 -current
by khw
in thread Building Perl 5.28.0 on OpenBSD 6.4 -current
by fishy
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |