[libcxx-commits] [libcxx] [libc++] Fix the locale base API on Linux with musl (PR #167980)

[Mr. Walls via libcxx-commits]

reactive-firewall wrote:

> > as the `__locale_dir/support/linux.h` still would report errors such as:
> 
> 
> 
> Why are such errors still reported? 

For Why... Please see the PR's linked github issue: llvm/llvm-project#167977 where you can find my initial report and go to the related links (they will take you to the various parts of the code)

> It seems that your build isn't using the `musl.h` header that was introduced at all? 

I believe it is using an older copy, however, one which is not relevant to these errors (the function calls on the libc++ side are to its own wrappers in `__locale_dir/support/linux.h` and that file is pulled in (I define -D__linux__ because the host OS is a linux kernel in this case, but would prefer to omit that if cmake could allow it)

> So is that a CMake configuration issue, i.e. is it that `_LIBCPP_HAS_MUSL_LIBC` is not defined properly when it should?

In the general case, maybe. In the case of these errors, no, the issue is the C functions are 
conditionally exposed by musl libc.

TL;DR - Musl can be built free of GNU source, so it does not define `_GNU_SOURCE` (e.g. zealously adhering to the C11 standard (ISO 9989:2011) for musl version v1.2.5). However if the _GNU_SOURCE is pre-defined when building musl, it will wrap a bunch of functions like the `strto`*`_l` functions for compatibility with code written for glibc (thus providing compatibility with C11+GNU extensions (i forget the exact iso 9989 designation).

In conclusion I'll add this PR was a break-fix not a feature implementation.

Hope this helps. Again thank you for your attention and time on this. :bow:

https://github.com/llvm/llvm-project/pull/167980