Skip to contentSkip to conversation

libcap: bump version

PATCH New Thomas Petazzoni 3 participants 15 messages Mar 16, 2016 – Mar 17, 2016

lore
Share & tools
lore
#0 lore raw

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
index 705bbc7..de24090 100644
@@ -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
index a7a9d13..a8579b7 100644
@@ -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
index 75822e5..a1dcd62 100644
@@ -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
index 8625139..bcb5d8c 100644
@@ -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
#1 lore raw

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
new file mode 100644
index 0000000..02cc228
@@ -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
#2 lore raw

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_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>.

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
#3 lore raw

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_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>.

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

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
#4 lore raw

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_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>.

Quoted 8 lines
Quoted 5 lines

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

My commit log is talking about XATTR_SECURITY_PREFIX, not XATTR_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_PREFIX defined ?

No, indeed not.

Quoted 1 line

I do have XATTR_CAPS_SUFFIX like you, but not XATTR_SECURITY_PREFIX.

Ok.

Signature · 2 lines
Venlig hilsen,
Peter Korsgaard 
#5 lore raw

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, not XATTR_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>"

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
#6 lore raw

PATCH 3/4 libcap, cdrkit, dvdrw-tools, fastd, squid: remove headers >= 3.0 dependency

In reply to Thomas Petazzoni

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.

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
index 46c0ba9..af18ba9 100644
@@ -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
index c9dd3dd..d4d6bd2 100644
@@ -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
index 55bdbd6..546d449 100644
@@ -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
index 2e3c8d9..5b0c827 100644
@@ -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
index 0ab6b37..12bfe19 100644
@@ -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
#7 lore raw

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.

Committed, thanks.

Signature · 1 line
Bye, Peter Korsgaard
#8 lore raw

PATCH 4/4 lxc: remove dependency on headers >= 3.0

In reply to Thomas Petazzoni

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 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
new file mode 100644
index 0000000..78c88f8
@@ -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
index 3253f14..acc561c 100644
@@ -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
#9 lore raw

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 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.

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
#10 lore raw

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
#11 lore raw

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 
#12 lore raw

PATCH 4/4 lxc: remove dependency on headers >= 3.0

In reply to Thomas Petazzoni
Quoted 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
#13 lore raw

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 
#14 lore raw

PATCH 1/4 libcap: bump version

In reply to Thomas Petazzoni
Quoted 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_CMDS

package/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