AaronBallman wrote: > This change broke building libcaca. That library conditionally uses > `<endian.h>` if available, and if available, it assumes that defines named > `__BYTE_ORDER` and `__BIG_ENDIAN` are defined by it - see > https://github.com/cacalabs/libcaca/blob/main/caca/caca_stubs.h#L43-L68. > > I'm not sure exactly which provider's `<endian.h>` this expects, but if it > can be reasonable that this header provides these defines with leading > underscores too, would it be reasonable to make it do that? > > If not, I guess the path forward is to patch this library to not use this > header (and possibly look for the compiler builtin defines `__BYTE_ORDER__` > and `__ORDER_BIG_ENDIAN__` instead).
That does seem to be allowed by the POSIX spec too (https://pubs.opengroup.org/onlinepubs/9799919799/basedefs/endian.h.html). `Implementations may define other macros with the _ENDIAN suffix.` https://github.com/llvm/llvm-project/pull/186032 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
