56bc0b1a37
macosx_getLocale (via getProcessLocale, both sal/osl/unx/osxlocale.cxx) obtains
from the system a locale string like "en-DE". (Whether that is even a sane and
recommended way to obtain the system locale on macOS I don't know; but lets
leave it at that for now.)
However, setting a locale env var (LANG, LC_ALL) to such a value causes a
constructor call std::locale("") to throw a std::runtime_error
"collate_byname<char>::collate_byname failed to construct for ", at least on
macOS 10.14.4. And libdivvun (which might be bundled with a LO extension) is
known to be hit by that, see <https://github.com/divvun/libdivvun/issues/28>
"locale("") gives 'collate_byname<char>::collate_byname failed to construct
for ' on LO on mac".
The code setting LC_ALL/LC_CTYPE/LANG was there ever since
|
||
|---|---|---|
| .. | ||
| android | ||
| cppunittester | ||
| inc | ||
| osl | ||
| qa | ||
| rtl | ||
| test | ||
| textenc | ||
| util | ||
| CppunitTest_Module_DLL.mk | ||
| CppunitTest_sal_comtools.mk | ||
| CppunitTest_sal_osl.mk | ||
| CppunitTest_sal_osl_security.mk | ||
| CppunitTest_sal_rtl.mk | ||
| CppunitTest_sal_types.mk | ||
| Executable_cppunittester.mk | ||
| Executable_osl_process_child.mk | ||
| Library_lo-bootstrap.mk | ||
| Library_sal.mk | ||
| Library_sal_textenc.mk | ||
| Makefile | ||
| Module_sal.mk | ||
| README | ||
System abstraction layer; rtl, osl and sal rtl: Platform independent strings osl: platform specific stuff, threads, dynamic loading, process, ipc, etc Exports only C API and some inline-methods (only C++ API).