196932cd91
Rick Felker suggested[1] this hack as a workaround to musl libc conflict with
kernel headers:
The problem is linux/libc-compat.h, which should fix this, only works
on glibc, by design. See:
#ifndef _LIBC_COMPAT_H
#define _LIBC_COMPAT_H
/* We have included glibc headers... */
#if defined(__GLIBC__)
/* Coordinate with glibc netinet/in.h header. */
#if defined(_NETINET_IN_H)
If you patch it like this:
-#if defined(__GLIBC__)
+#if 1
then it should mostly work but it's still all a big hack. I think
that's what distros are doing. The problem is that the same header is
trying to do two different things:
1. Provide extra linux-kernel-API stuff that's not in the
libc/userspace headers.
2. Provide definitions of the standard types and constants for uClibc
and klibc, which don't have complete libc headers and rely on the
kernel headers for definitions.
These two uses really should be separated out into separate headers so
that the latter only get included explicitly by uClibc and klibc and
otherwise remain completely unused. But that would require coordinated
changes/upgrades which are unlikely to happen. :(
Upstream musl still evaluates[2][3] a permanent solution.
With this in place we can revert (at least) commits
|
||
|---|---|---|
| .. | ||
| toolchain | ||
| toolchain-buildroot | ||
| toolchain-external | ||
| Config.in | ||
| helpers.mk | ||
| toolchain-common.in | ||
| toolchain-wrapper.c | ||
| toolchain-wrapper.mk | ||
| toolchain.mk | ||