Beefy Boxes and Bandwidth Generously Provided by pair Networks
Think about Loose Coupling

Re^4: Building Perl 5.28.0 on OpenBSD 6.4 -current

by khw (Novice)
on Nov 11, 2018 at 16:09 UTC ( #1225582=note: print w/replies, xml ) Need Help??

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

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.

  • Comment on Re^4: Building Perl 5.28.0 on OpenBSD 6.4 -current

Replies are listed 'Best First'.
Re^5: Building Perl 5.28.0 on OpenBSD 6.4 -current
by khw (Novice) on Nov 11, 2018 at 16:10 UTC
    I forgot to mention, that the Windows method predates the POSIX one by several years

      Having investigated further, the test is wrong, and you should just ignore the failures

      These are syntactically illegal setlocale() calls on OpenBSD, and so properly return failure. (The standard does not dictate a syntax for these, and different OS's are free to choose whatever they want. The tests use a syntax that is valid on Linux and Darwin.)

      On threaded builds, I wrote the code to accept different setlocale() syntaxes, but I didn't want to perturb (hence possibly break) anything on non-threaded builds, which is all that locales had worked under prior to 5.28.

      I will fix blead to skip these tests on unthreaded builds on OpenBSD, but I doubt that this problem will be considered severe enough to have the fix make it into a 5.28 maintenance release.

        Some further info. I didn't previously fully appreciate that the locale handling mechanism in openbsd is deliberately crippled out of security concerns. So testing of it, thinking it fully works, is going to fail. 5.30 will have new detection facilities for this sort of platform. Alpine linux or anything using the musl libc also has the same behavior.

        Thank you for your information and all your effort put into Perl!

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://1225582]
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others avoiding work at the Monastery: (6)
As of 2019-07-18 09:06 GMT
Find Nodes?
    Voting Booth?

    No recent polls found