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

[Mr. Walls via libcxx-commits]

reactive-firewall wrote:

@philnik777 
> Lastly, why do we check for `defined(_GNU_SOURCE)`? If we can get the `_l` variants, why do we not do that unconditionally?

Because it is a falsehood to assume we can get the `_l` variants on musl, see GHI llvm/llvm-project#167977 (short answer is MUSL switches based on `defined(_GNU_SOURCE)` when exporting these, and breaks builds of musl )

> More generally re. the patch, this is not how the locale base API is supposed to be implemented. Instead, a separate file should be added for musl in `__locale_dir/support/linux.h` which implements this for musl.
> 

I see the idea, as musl libc is possible to build with `-D_BSD_SOURCE` and should compleatly avoid the linux dependency assumptions in these cases, but I'm not sure where to start to make such a massive series of changes to libcxx (or I wouldn't need to use llvm's implementation)

This is a _GNU_SOURCE assumed without _GNU_SOURCE flaw in the libcxx wrapper. (but perhaps the wrapper should not be called when `#if ( _LIBCPP_HAS_MUSL_LIBC && !defined(_GNU_SOURCE))` instead (e.g. the contrapositive)?)

these changes are already in `__locale_dir/support/linux.h`, how would a separate file be inserted? and how would the switch work in cmake's config and where? Where is the contributor guide/doc/comment/etc. for more info on that approach.

@ldionne I have an example to help formulate a test for musl libc based building via a docker file: see [this dockerfile around lines 1-490](https://github.com/reactive-firewall/LLVM-Alpine-Musl/blob/68744a25da05f371ad2d27a83d4fc4308f3b8aaf/dockerfile#L1C1-L490C16) which fails due to GHI llvm/llvm-project#167977 ( e.g. see these [GHA logs](https://github.com/reactive-firewall/LLVM-Alpine-Musl/actions/runs/19346076270/job/55346787360#step:9:8033) )


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