Found while running a full C++23 workspace statically linked via the native mcpp path (openkal-llvm-runtime@0.1.3 + openkal-musl@0.3.5, x86_64-linux-musl).
openkal-musl port/include/features.h:146 defines musl's internal
visibility macro hidden. With the openkal include set active, any
consumer TU that textually includes C headers gets hidden defined as
__attribute__((__visibility__("hidden"))) — which breaks user code
using hidden as an ordinary identifier (we had two such locals). Could
the port shim keep that macro scoped to musl-internal builds?
Found while running a full C++23 workspace statically linked via the native mcpp path (openkal-llvm-runtime@0.1.3 + openkal-musl@0.3.5, x86_64-linux-musl).
openkal-muslport/include/features.h:146defines musl's internalvisibility macro
hidden. With the openkal include set active, anyconsumer TU that textually includes C headers gets
hiddendefined as__attribute__((__visibility__("hidden")))— which breaks user codeusing
hiddenas an ordinary identifier (we had two such locals). Couldthe port shim keep that macro scoped to musl-internal builds?