kumquat-buildroot/package/conntrack-tools/conntrack-tools.mk

26 lines
907 B
Makefile
Raw Normal View History

################################################################################
#
# conntrack-tools
#
################################################################################
CONNTRACK_TOOLS_VERSION = 1.4.5
CONNTRACK_TOOLS_SOURCE = conntrack-tools-$(CONNTRACK_TOOLS_VERSION).tar.bz2
CONNTRACK_TOOLS_SITE = http://www.netfilter.org/projects/conntrack-tools/files
CONNTRACK_TOOLS_DEPENDENCIES = host-pkgconf \
libnetfilter_conntrack libnetfilter_cthelper libnetfilter_cttimeout \
libnetfilter_queue host-bison host-flex
CONNTRACK_TOOLS_LICENSE = GPL-2.0+
CONNTRACK_TOOLS_LICENSE_FILES = COPYING
conntrack-tools: work around build issue with musl Building conntrack-tools with kernel headers >= 4.2 + musl fails due to a well-known symbol clash that occurs when userspace and kernel headers are included simultaneously (see [1], question 7, for details). In the case of conntrack-tools, the inclusion of both 'netinet/in.h' and 'linux/in.h' occurs inside the C helper files (src/helpers/*.c) indirectly via e.g. 'libnetfilter_conntrack/libnetfilter_conntrack.h', which itself includes 'netinet/in.h', and 'linux/netfilter.h', which includes 'linux/in.h' in kernel headers >= 4.2. The approach to solving this type of conflict with musl usually involves removing the inclusion of kernel headers or refactoring the code so as to avoid the mentioned simultaneous inclusion. This is unfortunately non-trivial in the case of conntrack-tools since the clashing headers get included indirectly by headers that are strictly necessary (because of definitions used in some helper callbacks). Work around the issue by defining __GLIBC__ when musl is used. This eliminates the conflicts as the kernel headers avoid redefining certain symbols when they see __GLIBC__ defined (linux/libc-compat.h). Note that other glibc-compatible libraries, like uClibc, already do that internally. Fixes: http://autobuild.buildroot.net/results/66e/66ec247fa0fc385bef8d2084c65bf5cad3a8e8ca/ http://autobuild.buildroot.net/results/624/624a0d48decd819eb58cbb3c58ee904b87ebfb21/ [1] http://wiki.musl-libc.org/wiki/FAQ Signed-off-by: Rodrigo Rebello <rprebello@gmail.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2015-11-30 16:40:39 +01:00
CONNTRACK_TOOLS_CFLAGS = $(TARGET_CFLAGS)
ifeq ($(BR2_PACKAGE_LIBTIRPC),y)
conntrack-tools: work around build issue with musl Building conntrack-tools with kernel headers >= 4.2 + musl fails due to a well-known symbol clash that occurs when userspace and kernel headers are included simultaneously (see [1], question 7, for details). In the case of conntrack-tools, the inclusion of both 'netinet/in.h' and 'linux/in.h' occurs inside the C helper files (src/helpers/*.c) indirectly via e.g. 'libnetfilter_conntrack/libnetfilter_conntrack.h', which itself includes 'netinet/in.h', and 'linux/netfilter.h', which includes 'linux/in.h' in kernel headers >= 4.2. The approach to solving this type of conflict with musl usually involves removing the inclusion of kernel headers or refactoring the code so as to avoid the mentioned simultaneous inclusion. This is unfortunately non-trivial in the case of conntrack-tools since the clashing headers get included indirectly by headers that are strictly necessary (because of definitions used in some helper callbacks). Work around the issue by defining __GLIBC__ when musl is used. This eliminates the conflicts as the kernel headers avoid redefining certain symbols when they see __GLIBC__ defined (linux/libc-compat.h). Note that other glibc-compatible libraries, like uClibc, already do that internally. Fixes: http://autobuild.buildroot.net/results/66e/66ec247fa0fc385bef8d2084c65bf5cad3a8e8ca/ http://autobuild.buildroot.net/results/624/624a0d48decd819eb58cbb3c58ee904b87ebfb21/ [1] http://wiki.musl-libc.org/wiki/FAQ Signed-off-by: Rodrigo Rebello <rprebello@gmail.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2015-11-30 16:40:39 +01:00
CONNTRACK_TOOLS_CFLAGS += `$(PKG_CONFIG_HOST_BINARY) --cflags libtirpc`
CONNTRACK_TOOLS_DEPENDENCIES += libtirpc host-pkgconf
endif
conntrack-tools: work around build issue with musl Building conntrack-tools with kernel headers >= 4.2 + musl fails due to a well-known symbol clash that occurs when userspace and kernel headers are included simultaneously (see [1], question 7, for details). In the case of conntrack-tools, the inclusion of both 'netinet/in.h' and 'linux/in.h' occurs inside the C helper files (src/helpers/*.c) indirectly via e.g. 'libnetfilter_conntrack/libnetfilter_conntrack.h', which itself includes 'netinet/in.h', and 'linux/netfilter.h', which includes 'linux/in.h' in kernel headers >= 4.2. The approach to solving this type of conflict with musl usually involves removing the inclusion of kernel headers or refactoring the code so as to avoid the mentioned simultaneous inclusion. This is unfortunately non-trivial in the case of conntrack-tools since the clashing headers get included indirectly by headers that are strictly necessary (because of definitions used in some helper callbacks). Work around the issue by defining __GLIBC__ when musl is used. This eliminates the conflicts as the kernel headers avoid redefining certain symbols when they see __GLIBC__ defined (linux/libc-compat.h). Note that other glibc-compatible libraries, like uClibc, already do that internally. Fixes: http://autobuild.buildroot.net/results/66e/66ec247fa0fc385bef8d2084c65bf5cad3a8e8ca/ http://autobuild.buildroot.net/results/624/624a0d48decd819eb58cbb3c58ee904b87ebfb21/ [1] http://wiki.musl-libc.org/wiki/FAQ Signed-off-by: Rodrigo Rebello <rprebello@gmail.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2015-11-30 16:40:39 +01:00
CONNTRACK_TOOLS_CONF_ENV = CFLAGS="$(CONNTRACK_TOOLS_CFLAGS)"
$(eval $(autotools-package))