libcap: bump version
PATCH 1/4 libcap: bump version
From: "Yann E. MORIN" <[email protected]>
attr is no longer a dependency, not even optional.
Refresh our patches, and drop the backport from upstream.
--- ...-build-system-fixes-for-cross-compilation.patch | 26 ++++-------- ...t-install-into-install-shared-install-sta.patch | 32 +++++++-------- ...nge-the-location-we-include-linux-xattr.h.patch | 46 ---------------------- package/libcap/libcap.hash | 2 +- package/libcap/libcap.mk | 18 +++------ 5 files changed, 29 insertions(+), 95 deletions(-) delete mode 100644 package/libcap/0003-Change-the-location-we-include-linux-xattr.h.patch
package/libcap/0001-build-system-fixes-for-cross-compilation.patch +7 -19
@@ -1,19 +1,19 @@ -From 7f48413ef1688df0d7fc25e477f4e6c0c55edfac Mon Sep 17 00:00:00 2001 +From d8d70559a279706c206761dfaf665d2197934123 Mon Sep 17 00:00:00 2001 From: Gustavo Zacarias <[email protected]> Date: Sun, 6 Mar 2016 22:52:02 +0100 Subject: [PATCH] build-system: fixes for cross-compilation Avoid the libcap buildsys forcing CC/CFLAGS/LDFLAGS/AR/RANLIB -Also install the shared lib +x Signed-off-by: Gustavo Zacarias <[email protected]> +[yann.morin.1998 at free.fr: dont chmod +x the shared lib] Signed-off-by: "Yann E. MORIN" <[email protected]> diff --git a/Make.Rules b/Make.Rules -index ec1c474..8a8fc50 100644 +index 8347b26..8a07a3f 100644 --- a/Make.Rules +++ b/Make.Rules -@@ -48,25 +48,25 @@ MINOR=24 +@@ -48,26 +48,26 @@ MINOR=25 KERNEL_HEADERS := $(topdir)/libcap/include/uapi IPATH += -fPIC -I$(KERNEL_HEADERS) -I$(topdir)/libcap/include
@@ -37,6 +37,7 @@ index ec1c474..8a8fc50 100644 LD=$(CC) -Wl,-x -shared -LDFLAGS := #-g +LDFLAGS ?= #-g + BUILD_GPERF := $(shell which gperf >/dev/null 2>/dev/null && echo yes) SYSTEM_HEADERS = /usr/include INCS=$(topdir)/libcap/include/sys/capability.h
@@ -44,22 +45,9 @@ index ec1c474..8a8fc50 100644 CFLAGS += -Dlinux $(WARNINGS) $(DEBUG) -PAM_CAP := $(shell if [ -f /usr/include/security/pam_modules.h ]; then echo yes ; else echo no ; fi) +PAM_CAP = no - INDENT := $(shell if [ -n "$(which indent 2>/dev/null)" ]; then echo "| indent -kr" ; fi) + INDENT := $(shell if [ -n "$$(which indent 2>/dev/null)" ]; then echo "| indent -kr" ; fi) DYNAMIC := $(shell if [ ! -d "$(topdir)/.git" ]; then echo yes; fi) - LIBATTR := yes -diff --git a/libcap/Makefile b/libcap/Makefile -index 20ab00f..97fea3f 100644 ---- a/libcap/Makefile -+++ b/libcap/Makefile -@@ -75,7 +75,7 @@ install: all - install -m 0644 include/sys/capability.h $(INCDIR)/sys - mkdir -p -m 0755 $(LIBDIR) - install -m 0644 $(STALIBNAME) $(LIBDIR)/$(STALIBNAME) -- install -m 0644 $(MINLIBNAME) $(LIBDIR)/$(MINLIBNAME) -+ install -m 0755 $(MINLIBNAME) $(LIBDIR)/$(MINLIBNAME) - ln -sf $(MINLIBNAME) $(LIBDIR)/$(MAJLIBNAME) - ln -sf $(MAJLIBNAME) $(LIBDIR)/$(LIBNAME) - ifeq ($(FAKEROOT),) + -- 1.9.1
package/libcap/0002-libcap-split-install-into-install-shared-install-sta.patch +16 -16
@@ -1,4 +1,4 @@ -From 8d7339169b9a5df2082731fe5468923be4be39af Mon Sep 17 00:00:00 2001 +From af21635665ab568f3333ff9fe8b474f4950e5acb Mon Sep 17 00:00:00 2001 From: Thomas Petazzoni <[email protected]> Date: Sun, 6 Mar 2016 22:53:24 +0100 Subject: [PATCH] libcap: split install into install-shared/install-static
@@ -11,10 +11,10 @@ Signed-off-by: Thomas Petazzoni <[email protected]> Signed-off-by: "Yann E. MORIN" <[email protected]> diff --git a/libcap/Makefile b/libcap/Makefile -index 97fea3f..7ac45dd 100644 +index d189777..44ddb27 100644 --- a/libcap/Makefile +++ b/libcap/Makefile -@@ -70,19 +70,25 @@ $(MINLIBNAME): $(OBJS) +@@ -62,19 +62,25 @@ $(MINLIBNAME): $(OBJS) cap_text.o: cap_text.c $(USE_GPERF_OUTPUT) $(INCLS) $(CC) $(CFLAGS) $(IPATH) $(INCLUDE_GPERF_OUTPUT) -c $< -o $@
@@ -22,24 +22,24 @@ index 97fea3f..7ac45dd 100644 +install: install-shared install-static + +install-common: - mkdir -p -m 0755 $(INCDIR)/sys - install -m 0644 include/sys/capability.h $(INCDIR)/sys -+ mkdir -p -m 0755 $(PKGCONFIGDIR) -+ install -m 0644 libcap.pc $(PKGCONFIGDIR)/libcap.pc - mkdir -p -m 0755 $(LIBDIR) + mkdir -p -m 0755 $(FAKEROOT)$(INCDIR)/sys + install -m 0644 include/sys/capability.h $(FAKEROOT)$(INCDIR)/sys ++ mkdir -p -m 0755 $(FAKEROOT)$(PKGCONFIGDIR) ++ install -m 0644 libcap.pc $(FAKEROOT)$(PKGCONFIGDIR)/libcap.pc + -+install-static: install-common - install -m 0644 $(STALIBNAME) $(LIBDIR)/$(STALIBNAME) ++install-static: $(STALIBNAME) install-common + mkdir -p -m 0755 $(FAKEROOT)$(LIBDIR) + install -m 0644 $(STALIBNAME) $(FAKEROOT)$(LIBDIR)/$(STALIBNAME) + -+install-shared: install-common - install -m 0755 $(MINLIBNAME) $(LIBDIR)/$(MINLIBNAME) - ln -sf $(MINLIBNAME) $(LIBDIR)/$(MAJLIBNAME) - ln -sf $(MAJLIBNAME) $(LIBDIR)/$(LIBNAME) ++install-shared: $(MINLIBNAME) install-common + install -m 0644 $(MINLIBNAME) $(FAKEROOT)$(LIBDIR)/$(MINLIBNAME) + ln -sf $(MINLIBNAME) $(FAKEROOT)$(LIBDIR)/$(MAJLIBNAME) + ln -sf $(MAJLIBNAME) $(FAKEROOT)$(LIBDIR)/$(LIBNAME) ifeq ($(FAKEROOT),) -/sbin/ldconfig endif -- mkdir -p -m 0755 $(PKGCONFIGDIR) -- install -m 0644 libcap.pc $(PKGCONFIGDIR)/libcap.pc +- mkdir -p -m 0755 $(FAKEROOT)$(PKGCONFIGDIR) +- install -m 0644 libcap.pc $(FAKEROOT)$(PKGCONFIGDIR)/libcap.pc clean: $(LOCALCLEAN)
package/libcap/0003-Change-the-location-we-include-linux-xattr.h.patch deleted +0 -46
46 lines not on this page · raw message
package/libcap/libcap.hash +1 -1
@@ -1,2 +1,2 @@ # https://www.kernel.org/pub/linux/libs/security/linux-privs/libcap2/sha256sums.asc -sha256 cee4568f78dc851d726fc93f25f4ed91cc223b1fe8259daa4a77158d174e6c65 libcap-2.24.tar.xz +sha256 693c8ac51e983ee678205571ef272439d83afe62dd8e424ea14ad9790bc35162 libcap-2.25.tar.xz
package/libcap/libcap.mk +5 -13
@@ -4,23 +4,16 @@ # ################################################################################ -LIBCAP_VERSION = 2.24 +LIBCAP_VERSION = 2.25 LIBCAP_SITE = https://www.kernel.org/pub/linux/libs/security/linux-privs/libcap2 LIBCAP_SOURCE = libcap-$(LIBCAP_VERSION).tar.xz LIBCAP_LICENSE = GPLv2 or BSD-3c LIBCAP_LICENSE_FILES = License -LIBCAP_DEPENDENCIES = host-libcap +LIBCAP_DEPENDENCIES = host-libcap host-gperf LIBCAP_INSTALL_STAGING = YES -ifeq ($(BR2_PACKAGE_ATTR),y) -LIBCAP_DEPENDENCIES += attr -LIBCAP_HAVE_LIBATTR = yes -else -LIBCAP_HAVE_LIBATTR = no -endif - -HOST_LIBCAP_DEPENDENCIES = host-attr +HOST_LIBCAP_DEPENDENCIES = host-gperf ifeq ($(BR2_STATIC_LIBS),y) LIBCAP_MAKE_TARGET = libcap.a libcap.pc
@@ -31,7 +24,6 @@ LIBCAP_MAKE_INSTALL_TARGET = install endif LIBCAP_MAKE_FLAGS = \ - LIBATTR=$(LIBCAP_HAVE_LIBATTR) \ BUILD_CC="$(HOSTCC)" \ BUILD_CFLAGS="$(HOST_CFLAGS)"
@@ -67,12 +59,12 @@ endef define HOST_LIBCAP_BUILD_CMDS $(HOST_MAKE_ENV) $(HOST_CONFIGURE_OPTS) $(MAKE) -C $(@D)\ - LIBATTR=yes RAISE_SETFCAP=no + RAISE_SETFCAP=no endef define HOST_LIBCAP_INSTALL_CMDS $(HOST_MAKE_ENV) $(MAKE) -C $(@D) DESTDIR=$(HOST_DIR) \ - LIBATTR=yes RAISE_SETFCAP=no prefix=/usr lib=lib install + RAISE_SETFCAP=no prefix=/usr lib=lib install endef $(eval $(generic-package))
Signature · 1 line
2.6.4
PATCH 2/4 libcap: add patch to fix build issue with old kernel headers
Old kernels (before 2.6.36) were defining XATTR_NAME_CAPS in <linux/capability.h>, but using XATTR_SECURITY_PREFIX and XATTR_CAPS_SUFFIX which were defined in the kernel-only part of <linux/xattr.h>.
In kernel 2.6.36 (commit af4f136056c984b0aa67feed7d3170b958370b2f), the XATTR_NAME_CAPS definition was moved to the kernel-only part of <linux/xattr.h>. It's only in kernel 3.0 (commit 1dbe39424a43e56a6c9aed12661192af51dcdb9f) that <linux/xattr.h> was fixed to expose XATTR_NAME_CAPS and the related definitions to userspace.
This is the reason why the target variant of libcap has a dependency on headers >= 3.0 for the moment.
However, this doesn't solve the problem for the host variant of libcap, which doesn't build properly on old systems.
To solve this, we simply add a patch that defines the missing definitions. Their values haven't changed over time since they are part of the kernel to userspace ABI.
Fixes:
http://autobuild.buildroot.org/results/856b71bccf14c3334a8c0fc66c1d985b09734313/
--- ..._file.c-fix-build-with-old-kernel-headers.patch | 51 ++++++++++++++++++++++ 1 file changed, 51 insertions(+) create mode 100644 package/libcap/0003-libcap-cap_file.c-fix-build-with-old-kernel-headers.patch
package/libcap/0003-libcap-cap_file.c-fix-build-with-old-kernel-headers.patch new file +51 -0
@@ -0,0 +1,51 @@ +From ace694e9574eb38e07cfe0db235434eb40003f47 Mon Sep 17 00:00:00 2001 +From: Thomas Petazzoni <[email protected]> +Date: Mon, 14 Mar 2016 22:39:15 +0100 +Subject: [PATCH] libcap/cap_file.c: fix build with old kernel headers + +Signed-off-by: Thomas Petazzoni <[email protected]> +--- + libcap/cap_file.c | 27 +++++++++++++++++++++++++++ + 1 file changed, 27 insertions(+) + +diff --git a/libcap/cap_file.c b/libcap/cap_file.c +index 40756ea..e3d54dd 100644 +--- a/libcap/cap_file.c ++++ b/libcap/cap_file.c +@@ -23,6 +23,33 @@ extern int fsetxattr(int, const char *, const void *, size_t, int); + extern int removexattr(const char *, const char *); + extern int fremovexattr(int, const char *); + ++ ++/* ++ * Old kernels (before 2.6.36) were defining XATTR_NAME_CAPS in ++ * <linux/capability.h>, but using XATTR_SECURITY_PREFIX and ++ * XATTR_CAPS_SUFFIX which were defined in the kernel-only part of ++ * <linux/xattr.h>. ++ * ++ * In kernel 2.6.36 (commit af4f136056c984b0aa67feed7d3170b958370b2f), ++ * the XATTR_NAME_CAPS definition was moved to the kernel-only part of ++ * <linux/xattr.h>. It's only in kernel 3.0 (commit ++ * 1dbe39424a43e56a6c9aed12661192af51dcdb9f) that <linux/xattr.h> was ++ * fixed to expose XATTR_NAME_CAPS and the related definitions to ++ * userspace. ++ * ++ * In order to cope with kernels < 3.0, we define here the appropriate ++ * values, which we assume haven't changed over history. ++ */ ++#ifndef XATTR_CAPS_SUFFIX ++#define XATTR_CAPS_SUFFIX "capability" ++#endif ++#ifndef XATTR_SECURITY_PREFIX ++#define XATTR_SECURITY_PREFIX "security." ++#endif ++#ifndef XATTR_NAME_CAPS ++#define XATTR_NAME_CAPS XATTR_SECURITY_PREFIX XATTR_CAPS_SUFFIX ++#endif ++ + #include "libcap.h" + + #ifdef VFS_CAP_U32 +-- +2.6.4 +
Signature · 1 line
2.6.4
PATCH 2/4 libcap: add patch to fix build issue with old kernel headers
Quoted 6 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Thomas" == Thomas Petazzoni <[email protected]> writes:
Old kernels (before 2.6.36) were defining
XATTR_NAME_CAPSin <linux/capability.h>, but usingXATTR_SECURITY_PREFIXandXATTR_CAPS_SUFFIXwhich were defined in the kernel-only part of <linux/xattr.h>.
gcc10 (which uses 2.6.32 headers) has XATTR_CAPS_SUFFIX in linux/capability.h:
#define XATTR_CAPS_SUFFIX "capability"
#define XATTR_NAME_CAPS XATTR_SECURITY_PREFIX XATTR_CAPS_SUFFIX
So this doesn't seem 100% correct, but the fix looks fine to me - So committed, thanks!
Signature · 1 line
Bye, Peter Korsgaard
PATCH 2/4 libcap: add patch to fix build issue with old kernel headers
Peter,
Quoted 10 lines · Peter Korsgaard
Quoted 4 lines
Old kernels (before 2.6.36) were defining
XATTR_NAME_CAPSin <linux/capability.h>, but usingXATTR_SECURITY_PREFIXandXATTR_CAPS_SUFFIXwhich were defined in the kernel-only part of <linux/xattr.h>.gcc10 (which uses 2.6.32 headers) has
XATTR_CAPS_SUFFIXinlinux/capability.h:#define
XATTR_CAPS_SUFFIX"capability"
#defineXATTR_NAME_CAPSXATTR_SECURITY_PREFIXXATTR_CAPS_SUFFIX
My commit log is talking about XATTR_SECURITY_PREFIX, not XATTR_CAPS_SUFFIX.
Do you have XATTR_SECURITY_PREFIX defined ?
I do have XATTR_CAPS_SUFFIX like you, but not XATTR_SECURITY_PREFIX.
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
PATCH 2/4 libcap: add patch to fix build issue with old kernel headers
Quoted 10 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Thomas" == Thomas Petazzoni <[email protected]> writes:
Peter,
Quoted 5 lines · Peter Korsgaard
Quoted 4 lines
Old kernels (before 2.6.36) were defining
XATTR_NAME_CAPSin <linux/capability.h>, but usingXATTR_SECURITY_PREFIXandXATTR_CAPS_SUFFIXwhich were defined in the kernel-only part of <linux/xattr.h>.
Quoted 8 lines
Quoted 5 lines
gcc10 (which uses 2.6.32 headers) has
XATTR_CAPS_SUFFIXinlinux/capability.h:#define
XATTR_CAPS_SUFFIX"capability"
#defineXATTR_NAME_CAPSXATTR_SECURITY_PREFIXXATTR_CAPS_SUFFIXMy commit log is talking about
XATTR_SECURITY_PREFIX, notXATTR_CAPS_SUFFIX.
Well, you wrote ".. but using XATTR_SECURITY_PREFIX and XATTR_CAPS_SUFFIX which were defined in the kernel-only part of <linux/xattr.h>"
Quoted 1 line
Do you have
XATTR_SECURITY_PREFIXdefined ?
No, indeed not.
Quoted 1 line
I do have
XATTR_CAPS_SUFFIXlike you, but notXATTR_SECURITY_PREFIX.
Ok.
Signature · 2 lines
Venlig hilsen, Peter Korsgaard
PATCH 2/4 libcap: add patch to fix build issue with old kernel headers
Hello,
Quoted 6 lines · Peter Korsgaard
Quoted 2 lines
My commit log is talking about
XATTR_SECURITY_PREFIX, notXATTR_CAPS_SUFFIX.Well, you wrote ".. but using
XATTR_SECURITY_PREFIXandXATTR_CAPS_SUFFIXwhich were defined in the kernel-only part of <linux/xattr.h>"
Gaah, bad commit log :-/ Sorry about that.
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
PATCH 3/4 libcap, cdrkit, dvdrw-tools, fastd, squid: remove headers >= 3.0 dependency
In reply to Thomas PetazzoniNow that the libcap package has a patch that makes it build with kernel headers < 3.0 (which was needed for the host variant of libcap), there is no longer a need to have a dependency on headers >= 3.0 for the target variant of libcap.
All reverse dependencies of libcap are handled in this commit, except lxc, which will be handled in a separate commit since it needs some special solution.
The build of all those packages has been tested with a toolchain that uses kernel headers 2.6.32, which is the oldest that our default glibc version accepts to use.
--- package/cdrkit/Config.in | 5 ----- package/dvdrw-tools/Config.in | 4 ---- package/fastd/Config.in | 4 +--- package/libcap/Config.in | 4 ---- package/squid/Config.in | 5 ++--- 5 files changed, 3 insertions(+), 19 deletions(-)
package/cdrkit/Config.in +0 -5
@@ -4,7 +4,6 @@ config BR2_PACKAGE_CDRKIT select BR2_PACKAGE_LIBCAP select BR2_PACKAGE_ZLIB depends on BR2_USE_MMU # fork - depends on BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_0 # libcap bool "cdrkit" help cdrkit is a suite of programs for recording CDs and DVDs,
@@ -12,7 +11,3 @@ config BR2_PACKAGE_CDRKIT extracting audio CD data, and more. http://www.cdrkit.org/ - -comment "cdrkit needs a toolchain w/ headers >= 3.0" - depends on BR2_USE_MMU - depends on !BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_0
package/dvdrw-tools/Config.in +0 -4
@@ -39,14 +39,10 @@ choice config BR2_PACKAGE_DVDRW_TOOLS_CDRKIT_BACKEND bool "cdrkit" - depends on BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_0 # cdrkit select BR2_PACKAGE_CDRKIT help Symlink mkisofs to genisoimage from the cdrkit package. -comment "cdrkit needs a toolchain w/ headers >= 3.0" - depends on !BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_0 - config BR2_PACKAGE_DVDRW_TOOLS_XORRISO_BACKEND bool "xorriso" select BR2_PACKAGE_XORRISO
package/fastd/Config.in +1 -3
@@ -2,7 +2,6 @@ config BR2_PACKAGE_FASTD bool "fastd" depends on BR2_USE_MMU # fork() depends on BR2_TOOLCHAIN_HAS_THREADS - depends on BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_0 # libcap depends on !BR2_STATIC_LIBS # libuecc select BR2_PACKAGE_LIBUECC select BR2_PACKAGE_LIBSODIUM
@@ -24,8 +23,7 @@ config BR2_PACKAGE_FASTD_STATUS_SOCKET endif -comment "fastd needs a toolchain w/ threads, headers >= 3.0, dynamic library" +comment "fastd needs a toolchain w/ threads, dynamic library" depends on BR2_USE_MMU depends on !BR2_TOOLCHAIN_HAS_THREADS \ - || !BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_0 \ || BR2_STATIC_LIBS
package/libcap/Config.in +0 -4
@@ -1,6 +1,5 @@ config BR2_PACKAGE_LIBCAP bool "libcap" - depends on BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_0 # XATTR_NAME_CAPS help This library implements the user-space interfaces to the POSIX 1003.1e capabilities available in Linux kernels. These
@@ -23,6 +22,3 @@ config BR2_PACKAGE_LIBCAP_TOOLS CONFIG_EXT2_FS_XATTR and CONFIG_EXT2_FS_SECURITY for ext2). endif - -comment "libcap needs a toolchain w/ headers >= 3.0" - depends on !BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_0
package/squid/Config.in +2 -3
@@ -1,13 +1,12 @@ -comment "squid needs a toolchain w/ C++, headers >= 3.0" +comment "squid needs a toolchain w/ C++" depends on BR2_USE_MMU - depends on !BR2_INSTALL_LIBSTDCPP || !BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_0 + depends on !BR2_INSTALL_LIBSTDCPP config BR2_PACKAGE_SQUID bool "squid" depends on BR2_INSTALL_LIBSTDCPP # needs fork() depends on BR2_USE_MMU - depends on BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_0 # libcap select BR2_PACKAGE_LIBCAP help Caching proxy for the Web supporting HTTP, HTTPS, FTP, and more.
Signature · 1 line
2.6.4
PATCH 3/4 libcap, cdrkit, dvdrw-tools, fastd, squid: remove headers >= 3.0 dependency
Quoted 11 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Thomas" == Thomas Petazzoni <[email protected]> writes:
Now that the libcap package has a patch that makes it build with kernel headers < 3.0 (which was needed for the host variant of libcap), there is no longer a need to have a dependency on headers >= 3.0 for the target variant of libcap.
All reverse dependencies of libcap are handled in this commit, except lxc, which will be handled in a separate commit since it needs some special solution.
Quoted 5 lines
The build of all those packages has been tested with a toolchain that uses kernel headers 2.6.32, which is the oldest that our default glibc version accepts to use.
Signed-off-by Thomas Petazzoni <[email protected]>
Committed, thanks.
Signature · 1 line
Bye, Peter Korsgaard
PATCH 4/4 lxc: remove dependency on headers >= 3.0
In reply to Thomas PetazzoniNow that libcap no longer needs kernel headers >= 3.0, we can remove this dependency from lxc. However, building with headers 2.6.32 exhibits a build issue caused by the redefinition of the setns() function.
Since setns() is not implemented in the C library, lxc provides its own version. However, for some reason, while the C library doesn't implement setns(), it provides a prototype for it, which is not exactly the same as the one in lxc, causing a build failure. We re-use a solution implemented in gdb to solve the same problem: define in lxc a function called do_setns(), which calls setns() when available, or manually does the system call otherwise.
Of course, with old kernels the system call will not be available, so things will fail at runtime, but this was anyway already the behavior of lxc's setns() dummy implementation.
--- ...0002-src-lxc-utils.h-don-t-redefine-setns.patch | 159 +++++++++++++++++++++ package/lxc/Config.in | 4 +- 2 files changed, 160 insertions(+), 3 deletions(-) create mode 100644 package/lxc/0002-src-lxc-utils.h-don-t-redefine-setns.patch
package/lxc/0002-src-lxc-utils.h-don-t-redefine-setns.patch new file +159 -0
@@ -0,0 +1,159 @@ +From fc111c5df2ce573f6d01c2a78405455aa4bc766c Mon Sep 17 00:00:00 2001 +From: Thomas Petazzoni <[email protected]> +Date: Wed, 16 Mar 2016 11:47:51 +0100 +Subject: [PATCH] src/lxc/utils.h: don't redefine setns() + +The current logic in src/lxc/utils.h consists in implementing a +setns() function if HAVE_SETNS is undefined. However, there are cases +where the autoconf setns() check will fail (and therefore HAVE_SETNS +will not be defined), but the C library does provide a setns() +prototype. Unfortunately, this prototype conflicts with the one used +internally in LXC. The C library headers define: + +extern int setns (int __fd, int __nstype) __THROW; + +While LXC defines: + +static inline int do_setns(int fd, int nstype) + +Which triggers the following build failures: + +utils.h:52:19: error: static declaration of 'setns' follows non-static declaration + static inline int setns(int fd, int nstype) + ^ +In file included from /home/test/buildroot2/output/host/usr/arm-buildroot-linux-gnueabi/sysroot/usr/include/sched.h:43:0, + from bdev.c:38: +/home/test/buildroot2/output/host/usr/arm-buildroot-linux-gnueabi/sysroot/usr/include/bits/sched.h:91:12: note: previous declaration of 'setns' was here + extern int setns (int __fd, int __nstype) __THROW; + +In order to resolve this problem, we adopt the solution that was +adopted by the gdb project at +https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commitdiff;h=a8c636cb54328fb9a71dcf27b66a7e7ab5443d88: +the function defined by LXC is renamed to do_setns(), and calls +setns() when available, or otherwise falls back on doing the system +calls manually. + +Signed-off-by: Thomas Petazzoni <[email protected]> +--- + src/lxc/attach.c | 2 +- + src/lxc/conf.c | 4 ++-- + src/lxc/lxc_user_nic.c | 4 ++-- + src/lxc/start.c | 2 +- + src/lxc/utils.c | 2 +- + src/lxc/utils.h | 9 ++++----- + 6 files changed, 11 insertions(+), 12 deletions(-) + +diff --git a/src/lxc/attach.c b/src/lxc/attach.c +index 436ae7a..953963f 100644 +--- a/src/lxc/attach.c ++++ b/src/lxc/attach.c +@@ -260,7 +260,7 @@ static int lxc_attach_to_ns(pid_t pid, int which) + } + + for (i = 0; i < size; i++) { +- if (fd[i] >= 0 && setns(fd[i], 0) != 0) { ++ if (fd[i] >= 0 && do_setns(fd[i], 0) != 0) { + saved_errno = errno; + + for (j = i; j < size; j++) +diff --git a/src/lxc/conf.c b/src/lxc/conf.c +index 55c2fae..8c7f16f 100644 +--- a/src/lxc/conf.c ++++ b/src/lxc/conf.c +@@ -2636,7 +2636,7 @@ void restore_phys_nics_to_netns(int netnsfd, struct lxc_conf *conf) + SYSERROR("Failed to open monitor netns fd"); + return; + } +- if (setns(netnsfd, 0) != 0) { ++ if (do_setns(netnsfd, 0) != 0) { + SYSERROR("Failed to enter container netns to reset nics"); + close(oldfd); + return; +@@ -2647,7 +2647,7 @@ void restore_phys_nics_to_netns(int netnsfd, struct lxc_conf *conf) + WARN("Error moving nic index:%d back to host netns", + s->ifindex); + } +- if (setns(oldfd, 0) != 0) ++ if (do_setns(oldfd, 0) != 0) + SYSERROR("Failed to re-enter monitor's netns"); + close(oldfd); + } +diff --git a/src/lxc/lxc_user_nic.c b/src/lxc/lxc_user_nic.c +index 6622db0..399e855 100644 +--- a/src/lxc/lxc_user_nic.c ++++ b/src/lxc/lxc_user_nic.c +@@ -492,7 +492,7 @@ static int rename_in_ns(int pid, char *oldname, char **newnamep) + fprintf(stderr, "Opening %s\n", nspath); + goto out_err; + } +- if (setns(fd, 0) < 0) { ++ if (do_setns(fd, 0) < 0) { + fprintf(stderr, "setns to container network namespace\n"); + goto out_err; + } +@@ -519,7 +519,7 @@ static int rename_in_ns(int pid, char *oldname, char **newnamep) + if (!*newnamep) + goto out_err; + } +- if (setns(ofd, 0) < 0) { ++ if (do_setns(ofd, 0) < 0) { + fprintf(stderr, "Error returning to original netns\n"); + close(ofd); + return -1; +diff --git a/src/lxc/start.c b/src/lxc/start.c +index fa905e2..2c76713 100644 +--- a/src/lxc/start.c ++++ b/src/lxc/start.c +@@ -157,7 +157,7 @@ static int attach_ns(const int ns_fd[LXC_NS_MAX]) { + if (ns_fd[i] < 0) + continue; + +- if (setns(ns_fd[i], 0) != 0) ++ if (do_setns(ns_fd[i], 0) != 0) + goto error; + } + return 0; +diff --git a/src/lxc/utils.c b/src/lxc/utils.c +index d9e769d..a696e0f 100644 +--- a/src/lxc/utils.c ++++ b/src/lxc/utils.c +@@ -1091,7 +1091,7 @@ bool switch_to_ns(pid_t pid, const char *ns) { + return false; + } + +- ret = setns(fd, 0); ++ ret = do_setns(fd, 0); + if (ret) { + SYSERROR("failed to set process %d to %s of %d.", pid, ns, fd); + close(fd); +diff --git a/src/lxc/utils.h b/src/lxc/utils.h +index 059026f..0f79ba0 100644 +--- a/src/lxc/utils.h ++++ b/src/lxc/utils.h +@@ -47,11 +47,11 @@ extern char *get_rundir(void); + #endif + #endif + +-/* Define setns() if missing from the C library */ +-#ifndef HAVE_SETNS +-static inline int setns(int fd, int nstype) ++static inline int do_setns(int fd, int nstype) + { +-#ifdef __NR_setns ++#ifdef HAVE_SETNS ++ return setns(fd, nstype); ++#elif defined(__NR_setns) + return syscall(__NR_setns, fd, nstype); + #elif defined(__NR_set_ns) + return syscall(__NR_set_ns, fd, nstype); +@@ -60,7 +60,6 @@ static inline int setns(int fd, int nstype) + return -1; + #endif + } +-#endif + + /* Define unshare() if missing from the C library */ + #ifndef HAVE_UNSHARE +-- +2.6.4 +
package/lxc/Config.in +1 -3
@@ -5,7 +5,6 @@ config BR2_PACKAGE_LXC depends on BR2_USE_MMU # fork() # build system forcefully builds a shared library depends on !BR2_STATIC_LIBS - depends on BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_0 # libcap help Linux Containers (LXC), provides the ability to group and isolate of a set of processes in a jail by virtualizing and accounting the
@@ -13,8 +12,7 @@ config BR2_PACKAGE_LXC https://linuxcontainers.org/ -comment "lxc needs a toolchain w/ threads, headers >= 3.0, dynamic library" +comment "lxc needs a toolchain w/ threads, dynamic library" depends on BR2_USE_MMU depends on !BR2_TOOLCHAIN_HAS_THREADS \ - || !BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_0 \ || BR2_STATIC_LIBS
Signature · 1 line
2.6.4
PATCH 4/4 lxc: remove dependency on headers >= 3.0
Quoted 15 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Thomas" == Thomas Petazzoni <[email protected]> writes:
Now that libcap no longer needs kernel headers >= 3.0, we can remove this dependency from lxc. However, building with headers 2.6.32 exhibits a build issue caused by the redefinition of the
setns()function.Since
setns()is not implemented in the C library, lxc provides its own version. However, for some reason, while the C library doesn't implementsetns(), it provides a prototype for it, which is not exactly the same as the one in lxc, causing a build failure. We re-use a solution implemented in gdb to solve the same problem: define in lxc a function calleddo_setns(), which callssetns()when available, or manually does the system call otherwise.
Quoted 3 lines
Of course, with old kernels the system call will not be available, so things will fail at runtime, but this was anyway already the behavior of lxc's
setns()dummy implementation.
But can missing setns() really just be ignored and still have a working lxc? From the code snippets failures look critical.
From the man page:
VERSIONS
The setns() system call first appeared in Linux in kernel 3.0; library support was added to glibc in version 2.14.
So I think it is safer to just keep the >= 3.0 headers dependency.
Signature · 1 line
Bye, Peter Korsgaard
PATCH 4/4 lxc: remove dependency on headers >= 3.0
Hello,
Quoted 2 lines · Peter Korsgaard
But can missing
setns()really just be ignored and still have a working lxc? From the code snippets failures look critical.
Yes, runtime it definitely won't work. But since the LXC code was already planning on being able to build on systems not providing those syscalls, I was staying in line with this decision.
Quoted 8 lines
From the man page:
VERSIONS
The
setns()system call first appeared in Linux in kernel 3.0; library support was added to glibc in version 2.14.So I think it is safer to just keep the >= 3.0 headers dependency.
But I agree with you, it's probably better to keep the >= 3.0 headers dependency. However, the comment that the dependency comes from libcap should be changed.
Should I change a patch to fix this?
Thanks,
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
PATCH 4/4 lxc: remove dependency on headers >= 3.0
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Thomas" == Thomas Petazzoni <[email protected]> writes:
Hi,
Quoted 10 lines
Quoted 4 lines
The
setns()system call first appeared in Linux in kernel 3.0; library support was added to glibc in version 2.14.So I think it is safer to just keep the >= 3.0 headers dependency.
But I agree with you, it's probably better to keep the >= 3.0 headers dependency. However, the comment that the dependency comes from libcap should be changed.
Should I change a patch to fix this?
Yes please!
Signature · 2 lines
Venlig hilsen, Peter Korsgaard
PATCH 4/4 lxc: remove dependency on headers >= 3.0
In reply to Thomas PetazzoniQuoted 15 lines · Thomas Petazzoni
Hello,
Quoted 2 lines · Peter Korsgaard
But can missing
setns()really just be ignored and still have a working lxc? From the code snippets failures look critical.Yes, runtime it definitely won't work. But since the LXC code was already planning on being able to build on systems not providing those syscalls, I was staying in line with this decision.
Quoted 4 lines
From the man page:
VERSIONS
Quoted 8 lines
Quoted 4 lines
The
setns()system call first appeared in Linux in kernel 3.0; library support was added to glibc in version 2.14.So I think it is safer to just keep the >= 3.0 headers dependency.
But I agree with you, it's probably better to keep the >= 3.0 headers dependency. However, the comment that the dependency comes from libcap should be changed.
Well, it would work with old kernel headers, as long as the actual kernel is
Quoted 1 line
= 3.0. But the only use case for that would be when using an old toolchain,
e.g. Arago. It's probably safer indeed to avoid runtime trouble by just depending on the headers version.
Regards,
Arnout
Quoted 7 lines
Should I change a patch to fix this?
Thanks,
Thomas
Signature · 6 lines
Arnout Vandecappelle arnout at mind be Senior Embedded Software Architect +32-16-286500 Essensium/Mind http://www.mind.be G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle GPG fingerprint: 7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF
PATCH 4/4 lxc: remove dependency on headers >= 3.0
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Arnout" == Arnout Vandecappelle <[email protected]> writes:
Hi,
Quoted 4 lines
Well, it would work with old kernel headers, as long as the actual
kernel is > = 3.0. But the only use case for that would be when using an old toolchain, e.g. Arago. It's probably safer indeed to avoid runtime trouble by just depending on the headers version.
Yes, or if the kernel has the setns syscall backported - But as we currently don't differ between build time (E.G. kernel headers) and runtime (actual kernel), then that's all we can do.
And I don't think we should introduce the extra complexity to have different symbols for kernel headers and runtime kernel versions.
Signature · 2 lines
Venlig hilsen, Peter Korsgaard
PATCH 1/4 libcap: bump version
In reply to Thomas PetazzoniQuoted 6 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Thomas" == Thomas Petazzoni <[email protected]> writes:
From: "Yann E. MORIN" <[email protected]> attr is no longer a dependency, not even optional.
Refresh our patches, and drop the backport from upstream.
It would have been good to mention something about the new host-gperf dependency, but ok.
package/libcap/libcap.mk endef · line 68
Quoted 11 lines
define
HOST_LIBCAP_BUILD_CMDSpackage/libcap/libcap.mk +2
-2$(HOST_MAKE_ENV) $(HOST_CONFIGURE_OPTS) $(MAKE) -C $(@D)\ - LIBATTR=yes RAISE_SETFCAP=no + RAISE_SETFCAP=no endef define HOST_LIBCAP_INSTALL_CMDS $(HOST_MAKE_ENV) $(MAKE) -C $(@D) DESTDIR=$(HOST_DIR) \ - LIBATTR=yes RAISE_SETFCAP=no prefix=/usr lib=lib install + RAISE_SETFCAP=no prefix=/usr lib=lib install endef
Not related to this bump, but this looks wrong. We shouldn't use DESTDIR / set prefix to /usr for host builds. From a quick look the prefix is at least used in libcap.pc, so other host packages will get wrong info if they use pkgconfig to find host-libcap.
Committed, thanks.
Signature · 1 line
Bye, Peter Korsgaard