For some reason libcxx wants to introduce their own musl macro to suppress use of __GLIBC_PREREQ rather than checking defined(__GLIBC__)...
-
-
Replying to @RichFelker
@RichFelker For linux libc-compat.h (coordinated header usage) I checked for defined(__GLIBC__) but left it open for other libc's.1 reply 0 retweets 0 likes -
Replying to @CarlosODonell
@patofiero I think it's right there because the inclusion-guard macro names are conceptually not a public API but poking at glibc internals.1 reply 0 retweets 0 likes -
Replying to @RichFelker
@patofiero We're discussing how to handle this with@musllibc & current proposal is just#define __UAPI_DEF_* 0 in appropriate places.1 reply 0 retweets 0 likes -
Replying to @RichFelker
@RichFelker@musllibc glibc has no UAPI defines. Keep all UAPI defines in in the linux kernel. Keep detection and definition distinct. $0.021 reply 0 retweets 0 likes -
Replying to @CarlosODonell
@patofiero Well I'd rather have a macro from stdc-predef.h that tells kernel hdrs "never define user types,#include libc hdrs to get them".1 reply 0 retweets 0 likes
@patofiero But I don't think the kernel ppl'd go 4 that. So I'd rather use their publ'd iface (__UAPI_DEF_*) than them peek at our internals
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.