kumquat-buildroot/toolchain/toolchain/toolchain.mk

51 lines
2.0 KiB
Makefile
Raw Normal View History

################################################################################
#
# toolchain
#
################################################################################
ifeq ($(BR2_TOOLCHAIN_BUILDROOT),y)
TOOLCHAIN_DEPENDENCIES += toolchain-buildroot
else ifeq ($(BR2_TOOLCHAIN_EXTERNAL),y)
TOOLCHAIN_DEPENDENCIES += toolchain-external
endif
TOOLCHAIN_ADD_TOOLCHAIN_DEPENDENCY = NO
toolchain: workaround musl/kernel headers conflict 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 a167081c5d (bridge-utils: fix build with musl) and e74d4fc4932 (norm: add patch to fix musl build). [1] http://www.openwall.com/lists/musl/2015/10/08/2 [2] http://git.musl-libc.org/cgit/musl/commit/?id=04983f2272382af92eb8f8838964ff944fbb8258 [3] http://www.openwall.com/lists/musl/2016/11/09/2 Signed-off-by: Baruch Siach <baruch@tkos.co.il> Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-11-10 14:27:11 +01:00
# Apply a hack that Rick Felker suggested[1] to avoid conflicts between libc
# headers and kernel headers. This is needed for kernel headers older than
# 4.15. Kernel headers 4.15 and newer don't require __GLIBC__ to be defined.
toolchain: workaround musl/kernel headers conflict 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 a167081c5d (bridge-utils: fix build with musl) and e74d4fc4932 (norm: add patch to fix musl build). [1] http://www.openwall.com/lists/musl/2015/10/08/2 [2] http://git.musl-libc.org/cgit/musl/commit/?id=04983f2272382af92eb8f8838964ff944fbb8258 [3] http://www.openwall.com/lists/musl/2016/11/09/2 Signed-off-by: Baruch Siach <baruch@tkos.co.il> Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-11-10 14:27:11 +01:00
#
# Augment the original suggestion with __USE_MISC since recent kernels
# (older than 4.15) require this glibc internal macro. Also, as musl defines
# IFF_LOWER_UP, IFF_DORMANT and IFF_ECHO, add another macro to suppress
# them in the kernel header, and avoid macro/enum conflict.
#
# Kernel version 3.12 introduced the libc-compat.h header.
#
toolchain: workaround musl/kernel headers conflict 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 a167081c5d (bridge-utils: fix build with musl) and e74d4fc4932 (norm: add patch to fix musl build). [1] http://www.openwall.com/lists/musl/2015/10/08/2 [2] http://git.musl-libc.org/cgit/musl/commit/?id=04983f2272382af92eb8f8838964ff944fbb8258 [3] http://www.openwall.com/lists/musl/2016/11/09/2 Signed-off-by: Baruch Siach <baruch@tkos.co.il> Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-11-10 14:27:11 +01:00
# [1] http://www.openwall.com/lists/musl/2015/10/08/2
ifeq ($(BR2_TOOLCHAIN_USES_MUSL)$(BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_12):$(BR2_TOOLCHAIN_HEADERS_AT_LEAST_4_15),yy:)
toolchain: workaround musl/kernel headers conflict 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 a167081c5d (bridge-utils: fix build with musl) and e74d4fc4932 (norm: add patch to fix musl build). [1] http://www.openwall.com/lists/musl/2015/10/08/2 [2] http://git.musl-libc.org/cgit/musl/commit/?id=04983f2272382af92eb8f8838964ff944fbb8258 [3] http://www.openwall.com/lists/musl/2016/11/09/2 Signed-off-by: Baruch Siach <baruch@tkos.co.il> Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-11-10 14:27:11 +01:00
define TOOLCHAIN_MUSL_KERNEL_HEADERS_COMPATIBILITY_HACK
$(SED) 's/^#if defined(__GLIBC__)$$/#if 1/' \
$(STAGING_DIR)/usr/include/linux/libc-compat.h
$(SED) '1s/^/#define __USE_MISC\n/' \
$(STAGING_DIR)/usr/include/linux/libc-compat.h
$(SED) '1s/^/#define __UAPI_DEF_IF_NET_DEVICE_FLAGS_LOWER_UP_DORMANT_ECHO 0\n/' \
$(STAGING_DIR)/usr/include/linux/libc-compat.h
toolchain: workaround musl/kernel headers conflict 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 a167081c5d (bridge-utils: fix build with musl) and e74d4fc4932 (norm: add patch to fix musl build). [1] http://www.openwall.com/lists/musl/2015/10/08/2 [2] http://git.musl-libc.org/cgit/musl/commit/?id=04983f2272382af92eb8f8838964ff944fbb8258 [3] http://www.openwall.com/lists/musl/2016/11/09/2 Signed-off-by: Baruch Siach <baruch@tkos.co.il> Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-11-10 14:27:11 +01:00
endef
TOOLCHAIN_POST_INSTALL_STAGING_HOOKS += TOOLCHAIN_MUSL_KERNEL_HEADERS_COMPATIBILITY_HACK
TOOLCHAIN_INSTALL_STAGING = YES
endif
# Install default nsswitch.conf file if the skeleton doesn't provide it
ifeq ($(BR2_TOOLCHAIN_USES_GLIBC),y)
define GLIBC_COPY_NSSWITCH_FILE
@if [ ! -f "$(TARGET_DIR)/etc/nsswitch.conf" ]; then \
$(INSTALL) -D -m 0644 package/glibc/nsswitch.conf $(TARGET_DIR)/etc/nsswitch.conf ; \
fi
endef
TOOLCHAIN_POST_INSTALL_TARGET_HOOKS += GLIBC_COPY_NSSWITCH_FILE
endif
$(eval $(virtual-package))