locale("") gives 'collate_byname<char>::collate_byname failed to construct for ' on LO on mac

[unhammer]

The https://github.com/divvun/libreoffice-divvun extension built with libdivvun 0.3.3 crashes/hangs in LibreOffice on mac.

After compiling a debug build of LO we see the following output:

…
warn:linguistic:67283:363302:linguistic/source/gciterator.cxx:679: GrammarCheckingIterator::DequeueAndCheck ignoring N3com3sun4star3uno9ExceptionE msg: C++ code threw St13runtime_error: collate_byname<char>::collate_byname failed to construct for 
…
warn:legacy.osl:67283:361460:sw/source/uibase/dialog/SwSpellDialogChildWindow.cxx:430: ApplyChangedSentence in initial call or after resume

Running that through lldb (make debugrun in LO) and fiddling with breakpoints (first b linguistic/source/gciterator.cxx:607, c, then break set -E cxx and c; bt; c; bt …), we see that the error thrown is

 thread #18, name = 'GrammarCheckingIterator', stop reason = breakpoint 2.2
    frame #0: 0x00007fff7767d80b libc++abi.dylib`__cxa_rethrow
libc++abi.dylib`__cxa_rethrow:
->  0x7fff7767d80b <+0>: pushq  %rbp
    0x7fff7767d80c <+1>: movq   %rsp, %rbp
    0x7fff7767d80f <+4>: pushq  %r15
    0x7fff7767d811 <+6>: pushq  %r14
Target 0: (soffice) stopped.
(lldb) bt
* thread #18, name = 'GrammarCheckingIterator', stop reason = breakpoint 2.2
  * frame #0: 0x00007fff7767d80b libc++abi.dylib`__cxa_rethrow
    frame #1: 0x00007fff77653ffe libc++.1.dylib`std::__1::locale::__imp::__imp(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, unsigned long) + 2162
    frame #2: 0x00007fff776553c8 libc++.1.dylib`std::__1::locale::locale(char const*) + 186
    frame #3: 0x00000001763d8389 libdivvun.0.dylib`divvun::getCasing(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >) + 73

ie. the reason seems to be that in getCasing we call std::locale("") which then fails with collate_byname<char>::collate_byname failed to construct for .

But why does it work when running LO-bundled python-interpreter on the LO-extension from the command line? (And shouldn't the "" be a valid fallback locale?)

[snomos]

What is the locale of the LO instance, and what is the locale of the command line running the python-interpreter? If the command line environment is UTF 8 and LO is not, could that explain the difference?

[unhammer]

I'm running both soffice and python3 from the same command line

[unhammer]

#[email protected]'s <sberg> says:

 the std::locale("") exception is due to the various
 setenv in our MACOSX-specific imp_getProcessLocale
 (sal/osl/unx/nlsupport.cxx); I'll deal with that later (it's probably
 just cargo cult that can just be removed, but would need some more
 testing for that)