[Buildroot] [PATCH v2 1/3] toolchain: workaround musl/kernel headers conflict

[Buildroot] [PATCH v2 1/3] toolchain: workaround musl/kernel headers conflict

[Baruch Siach]

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>
---
v2:
  * Add Rick's explanation in the commit log (Arnout)
  * Link to more recent upstream changes
---
 toolchain/toolchain/toolchain.mk | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/toolchain/toolchain/toolchain.mk b/toolchain/toolchain/toolchain.mk
index c22713bfe349..d317e917d032 100644
--- a/toolchain/toolchain/toolchain.mk
+++ b/toolchain/toolchain/toolchain.mk
@@ -12,6 +12,20 @@ endif
 
 TOOLCHAIN_ADD_TOOLCHAIN_DEPENDENCY = NO
 
+# Apply a hack that Rick Felker suggested[1] to avoid conflicts between libc
+# headers and kernel headers. This is a temporary measure until musl finds a
+# better solution.
+#
+# [1] http://www.openwall.com/lists/musl/2015/10/08/2
+ifeq ($(BR2_TOOLCHAIN_USES_MUSL),y)
+define TOOLCHAIN_MUSL_KERNEL_HEADERS_COMPATIBILITY_HACK
+	$(SED) 's/^#if defined(__GLIBC__)$$/#if 1/' \
+		$(STAGING_DIR)/usr/include/linux/libc-compat.h
+endef
+TOOLCHAIN_POST_INSTALL_STAGING_HOOKS += TOOLCHAIN_MUSL_KERNEL_HEADERS_COMPATIBILITY_HACK
+TOOLCHAIN_INSTALL_STAGING = YES
+endif
+
 $(eval $(virtual-package))
 
 toolchain: $(HOST_DIR)/usr/share/buildroot/toolchainfile.cmake
-- 
2.10.2

[Buildroot] [PATCH v2 2/3] Revert "bridge-utils: fix build with musl"

[Baruch Siach]

This reverts commit a167081c5d5a5aee95b642a14200d18d8a84dbcc.

With the applied musl/kernel headers conflict workaround this upstream nacked
patch is no longer necessary.

Signed-off-by: Baruch Siach <baruch@tkos.co.il>
---
 ...ridge-fix-headers-conflict-with-musl-libc.patch | 140 ---------------------
 1 file changed, 140 deletions(-)
 delete mode 100644 package/bridge-utils/0002-libbridge-fix-headers-conflict-with-musl-libc.patch

diff --git a/package/bridge-utils/0002-libbridge-fix-headers-conflict-with-musl-libc.patch b/package/bridge-utils/0002-libbridge-fix-headers-conflict-with-musl-libc.patch
deleted file mode 100644
index fd7f45ed4e03..000000000000
--- a/package/bridge-utils/0002-libbridge-fix-headers-conflict-with-musl-libc.patch
+++ /dev/null
@@ -1,140 +0,0 @@
-From 24e5409190820a14e4d097924b1acaab62bb3b99 Mon Sep 17 00:00:00 2001
-From: Baruch Siach <baruch@tkos.co.il>
-Date: Sun, 30 Oct 2016 18:12:00 +0200
-Subject: [PATCH] libbridge: fix headers conflict with musl libc
-
-Don't including kernel headers directly to avoid headers conflict like:
-
-In file included from .../sysroot/usr/include/linux/if_bridge.h:18:0,
-                 from libbridge.h:26,
-                 from libbridge_if.c:26:
-.../sysroot/usr/include/linux/in6.h:32:8: error: redefinition of ?struct in6_addr?
- struct in6_addr {
-        ^
-In file included from libbridge.h:24:0,
-                 from libbridge_if.c:26:
-.../sysroot/usr/include/netinet/in.h:23:8: note: originally defined here
- struct in6_addr {
-        ^
-
-Instead copy the required linux/if_bridge.h definitions into
-libbridge_private.h.
-
-Signed-off-by: Baruch Siach <baruch@tkos.co.il>
----
-Patch status: Nacked
-(https://lists.linuxfoundation.org/pipermail/bridge/2016-November/010107.html)
----
- libbridge/libbridge.h         |  1 -
- libbridge/libbridge_private.h | 83 ++++++++++++++++++++++++++++++++++++++++++-
- 2 files changed, 82 insertions(+), 2 deletions(-)
-
-diff --git a/libbridge/libbridge.h b/libbridge/libbridge.h
-index ff047f933cd6..18b40cd90413 100644
---- a/libbridge/libbridge.h
-+++ b/libbridge/libbridge.h
-@@ -23,7 +23,6 @@
- #include <sys/socket.h>
- #include <netinet/in.h>
- #include <linux/if.h>
--#include <linux/if_bridge.h>
- 
- /* defined in net/if.h but that conflicts with linux/if.h... */
- extern unsigned int if_nametoindex (const char *__ifname);
-diff --git a/libbridge/libbridge_private.h b/libbridge/libbridge_private.h
-index 99a511dae00a..565025b7bccb 100644
---- a/libbridge/libbridge_private.h
-+++ b/libbridge/libbridge_private.h
-@@ -24,7 +24,88 @@
- #include <linux/sockios.h>
- #include <sys/time.h>
- #include <sys/ioctl.h>
--#include <linux/if_bridge.h>
-+
-+/* From linux/if_ether.h */
-+#ifndef ETH_ALEN
-+#define ETH_ALEN	6
-+#endif
-+
-+/* From linux/if_bridge.h */
-+#ifndef BRCTL_GET_VERSION
-+#define BRCTL_GET_VERSION 0
-+#define BRCTL_GET_BRIDGES 1
-+#define BRCTL_ADD_BRIDGE 2
-+#define BRCTL_DEL_BRIDGE 3
-+#define BRCTL_ADD_IF 4
-+#define BRCTL_DEL_IF 5
-+#define BRCTL_GET_BRIDGE_INFO 6
-+#define BRCTL_GET_PORT_LIST 7
-+#define BRCTL_SET_BRIDGE_FORWARD_DELAY 8
-+#define BRCTL_SET_BRIDGE_HELLO_TIME 9
-+#define BRCTL_SET_BRIDGE_MAX_AGE 10
-+#define BRCTL_SET_AGEING_TIME 11
-+#define BRCTL_SET_GC_INTERVAL 12
-+#define BRCTL_GET_PORT_INFO 13
-+#define BRCTL_SET_BRIDGE_STP_STATE 14
-+#define BRCTL_SET_BRIDGE_PRIORITY 15
-+#define BRCTL_SET_PORT_PRIORITY 16
-+#define BRCTL_SET_PATH_COST 17
-+#define BRCTL_GET_FDB_ENTRIES 18
-+
-+#define BR_STATE_DISABLED 0
-+#define BR_STATE_LISTENING 1
-+#define BR_STATE_LEARNING 2
-+#define BR_STATE_FORWARDING 3
-+#define BR_STATE_BLOCKING 4
-+
-+struct __bridge_info {
-+	__u64 designated_root;
-+	__u64 bridge_id;
-+	__u32 root_path_cost;
-+	__u32 max_age;
-+	__u32 hello_time;
-+	__u32 forward_delay;
-+	__u32 bridge_max_age;
-+	__u32 bridge_hello_time;
-+	__u32 bridge_forward_delay;
-+	__u8 topology_change;
-+	__u8 topology_change_detected;
-+	__u8 root_port;
-+	__u8 stp_enabled;
-+	__u32 ageing_time;
-+	__u32 gc_interval;
-+	__u32 hello_timer_value;
-+	__u32 tcn_timer_value;
-+	__u32 topology_change_timer_value;
-+	__u32 gc_timer_value;
-+};
-+
-+struct __port_info {
-+	__u64 designated_root;
-+	__u64 designated_bridge;
-+	__u16 port_id;
-+	__u16 designated_port;
-+	__u32 path_cost;
-+	__u32 designated_cost;
-+	__u8 state;
-+	__u8 top_change_ack;
-+	__u8 config_pending;
-+	__u8 unused0;
-+	__u32 message_age_timer_value;
-+	__u32 forward_delay_timer_value;
-+	__u32 hold_timer_value;
-+};
-+
-+struct __fdb_entry {
-+	__u8 mac_addr[ETH_ALEN];
-+	__u8 port_no;
-+	__u8 is_local;
-+	__u32 ageing_timer_value;
-+	__u8 port_hi;
-+	__u8 pad0;
-+	__u16 unused;
-+};
-+#endif /* BRCTL_GET_VERSION */
- 
- #define MAX_BRIDGES	1024
- #define MAX_PORTS	1024
--- 
-2.10.1
-
-- 
2.10.2

[Buildroot] [PATCH v2 3/3] Revert "norm: add patch to fix musl build"

[Baruch Siach]

This reverts commit e74d4fc4932df4ea42381acb44d616241275b79a.

With the applied musl/kernel headers conflict workaround this patch is no
longer necessary.

Signed-off-by: Baruch Siach <baruch@tkos.co.il>
---
 ...03-remove-kernel-headers-include-musl-fix.patch | 55 ----------------------
 1 file changed, 55 deletions(-)
 delete mode 100644 package/norm/0003-remove-kernel-headers-include-musl-fix.patch

diff --git a/package/norm/0003-remove-kernel-headers-include-musl-fix.patch b/package/norm/0003-remove-kernel-headers-include-musl-fix.patch
deleted file mode 100644
index 7581c10b79bb..000000000000
--- a/package/norm/0003-remove-kernel-headers-include-musl-fix.patch
+++ /dev/null
@@ -1,55 +0,0 @@
-Remove kernel header includes causing issues with musl
-
-Include the kernel headers from netfilter causes a conflict with the
-<netinet/in.h> way of defining the IPPROTO_* constants, resulting in
-the following build failure:
-
-In file included from /home/peko/autobuild/instance-0/output/host/usr/arm-buildroot-linux-musleabihf/sysroot/usr/include/netdb.h:9:0,
-                 from /home/peko/autobuild/instance-0/output/build/norm-1.5r6/protolib/include/protoAddress.h:13,
-                 from /home/peko/autobuild/instance-0/output/build/norm-1.5r6/protolib/include/protoDetour.h:5,
-                 from ../protolib/src/linux/linuxDetour.cpp:3:
-/home/peko/autobuild/instance-0/output/host/usr/arm-buildroot-linux-musleabihf/sysroot/usr/include/linux/in.h:28:3: error: expected identifier before numeric constant
-   IPPROTO_IP = 0,  /* Dummy protocol for TCP  */
-   ^
-/home/peko/autobuild/instance-0/output/host/usr/arm-buildroot-linux-musleabihf/sysroot/usr/include/linux/in.h:28:3: error: expected '}' before numeric constant
-/home/peko/autobuild/instance-0/output/host/usr/arm-buildroot-linux-musleabihf/sysroot/usr/include/linux/in.h:28:3: error: expected unqualified-id before numeric constant
-In file included from /home/peko/autobuild/instance-0/output/host/usr/arm-buildroot-linux-musleabihf/sysroot/usr/include/linux/netfilter.h:7:0,
-                 from /home/peko/autobuild/instance-0/output/host/usr/arm-buildroot-linux-musleabihf/sysroot/usr/include/linux/netfilter_ipv4.h:8,
-                 from ../protolib/src/linux/linuxDetour.cpp:10:
-/home/peko/autobuild/instance-0/output/host/usr/arm-buildroot-linux-musleabihf/sysroot/usr/include/linux/in.h:79:1: error: expected declaration before '}' token
- };
- ^
-
-Since from musl's developers perspective including kernel headers is
-seen as being unsafe, we simply duplicate the necessary netfilter
-definitions (there are just a few) instead of including some kernel
-headers.
-
-Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
-
-Index: b/protolib/src/linux/linuxDetour.cpp
-===================================================================
---- a/protolib/src/linux/linuxDetour.cpp
-+++ b/protolib/src/linux/linuxDetour.cpp
-@@ -7,15 +7,18 @@
- #include <stdlib.h>  // for atoi(), getenv()
- #include <stdio.h>
- #include <unistd.h>  // for close()
--#include <linux/netfilter_ipv4.h>  // for NF_IP_LOCAL_OUT, etc
--#include <linux/netfilter_ipv6.h>  // for NF_IP6_LOCAL_OUT, etc
--#include <linux/netfilter.h>  // for NF_ACCEPT, etc
- #include <libnetfilter_queue/libnetfilter_queue.h>
- 
- #include <fcntl.h>  // for fcntl(), etc
- #include <linux/if_ether.h>  // for ETH_P_IP
- #include <net/if_arp.h>   // for ARPHRD_ETHER
- 
-+/* From netfilter kernel headers */
-+#define NF_IP_LOCAL_OUT		3
-+
-+#define NF_DROP 		0
-+#define NF_ACCEPT 		1
-+
- /** NOTES: 
-  *
-  * 1) This newer implementation of LinuxDetour uses netfilter_queue
-- 
2.10.2

[Buildroot] [PATCH v2 1/3] toolchain: workaround musl/kernel headers conflict

[Arnout Vandecappelle]

On 10-11-16 14:27, Baruch Siach wrote:
> 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>

 As mentioned in response to v1, I really would prefer this to be part of
musl-compat-headers, so that we have one place to collect all musl hacks.
However, that would be a bit more intricate, because it would require
musl-compat-headers to be built _after_ musl or the external toolchain, which
makes for some complicated dependency chains. So I'm fine with this solution.

 However, if bridge-utils and norm are really the only packages that suffer from
this problem, is it really worthwhile to apply this workaround?

 Regards,
 Arnout

> ---
> v2:
>   * Add Rick's explanation in the commit log (Arnout)
>   * Link to more recent upstream changes
> ---
>  toolchain/toolchain/toolchain.mk | 14 ++++++++++++++
>  1 file changed, 14 insertions(+)
> 
> diff --git a/toolchain/toolchain/toolchain.mk b/toolchain/toolchain/toolchain.mk
> index c22713bfe349..d317e917d032 100644
> --- a/toolchain/toolchain/toolchain.mk
> +++ b/toolchain/toolchain/toolchain.mk
> @@ -12,6 +12,20 @@ endif
>  
>  TOOLCHAIN_ADD_TOOLCHAIN_DEPENDENCY = NO
>  
> +# Apply a hack that Rick Felker suggested[1] to avoid conflicts between libc
> +# headers and kernel headers. This is a temporary measure until musl finds a
> +# better solution.
> +#
> +# [1] http://www.openwall.com/lists/musl/2015/10/08/2
> +ifeq ($(BR2_TOOLCHAIN_USES_MUSL),y)
> +define TOOLCHAIN_MUSL_KERNEL_HEADERS_COMPATIBILITY_HACK
> +	$(SED) 's/^#if defined(__GLIBC__)$$/#if 1/' \
> +		$(STAGING_DIR)/usr/include/linux/libc-compat.h
> +endef
> +TOOLCHAIN_POST_INSTALL_STAGING_HOOKS += TOOLCHAIN_MUSL_KERNEL_HEADERS_COMPATIBILITY_HACK
> +TOOLCHAIN_INSTALL_STAGING = YES
> +endif
> +
>  $(eval $(virtual-package))
>  
>  toolchain: $(HOST_DIR)/usr/share/buildroot/toolchainfile.cmake
> 

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

[Buildroot] [PATCH v2 1/3] toolchain: workaround musl/kernel headers conflict

[Thomas Petazzoni]

Hello,

On Sun, 13 Nov 2016 22:33:31 +0100, Arnout Vandecappelle wrote:

>  However, if bridge-utils and norm are really the only packages that suffer from
> this problem, is it really worthwhile to apply this workaround?

I'm sure there are more packages that we have patched for this reason,
and possibly other build failures still unfixed that would get fixed
(or at least partially).

*However*, the musl folks have already committed a patch that
apparently resolves the problem:

   http://git.musl-libc.org/cgit/musl/commit/?id=04983f2272382af92eb8f8838964ff944fbb8258

Baruch, could you investigate whether this musl commit fixes the header
conflict problem for bridge-utils and norm?

Thanks!

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[Buildroot] [PATCH v2 1/3] toolchain: workaround musl/kernel headers conflict

[Baruch Siach]

Hi Thomas,

On Tue, Nov 15, 2016 at 11:33:47PM +0100, Thomas Petazzoni wrote:
> On Sun, 13 Nov 2016 22:33:31 +0100, Arnout Vandecappelle wrote:
> 
> >  However, if bridge-utils and norm are really the only packages that suffer from
> > this problem, is it really worthwhile to apply this workaround?
> 
> I'm sure there are more packages that we have patched for this reason,
> and possibly other build failures still unfixed that would get fixed
> (or at least partially).
> 
> *However*, the musl folks have already committed a patch that
> apparently resolves the problem:
> 
>    http://git.musl-libc.org/cgit/musl/commit/?id=04983f2272382af92eb8f8838964ff944fbb8258
> 
> Baruch, could you investigate whether this musl commit fixes the header
> conflict problem for bridge-utils and norm?

The commit log links to this musl commit and to a mailing list report[1] that 
this fix is not enough on its own. As a result of this discussion Felix Janda 
posted a kernel patch[2] to address the issue. See also Rich's response[3]. 
Even if this patch is accepted, we'll most likely have to keep this 
workaround, or an equivalent, for as long as we support kernel headers v4.9 
and older.

[1] http://www.openwall.com/lists/musl/2016/11/09/2
[2] http://www.openwall.com/lists/musl/2016/11/11/1
[3] http://www.openwall.com/lists/musl/2016/11/11/2

baruch

-- 
     http://baruch.siach.name/blog/                  ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch at tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -

[Buildroot] [PATCH v2 1/3] toolchain: workaround musl/kernel headers conflict

[Thomas Petazzoni]

Hello,

On Wed, 16 Nov 2016 17:45:16 +0200, Baruch Siach wrote:

> > Baruch, could you investigate whether this musl commit fixes the header
> > conflict problem for bridge-utils and norm?  
> 
> The commit log links to this musl commit and to a mailing list report[1] that 
> this fix is not enough on its own. As a result of this discussion Felix Janda 
> posted a kernel patch[2] to address the issue. See also Rich's response[3]. 
> Even if this patch is accepted, we'll most likely have to keep this 
> workaround, or an equivalent, for as long as we support kernel headers v4.9 
> and older.
> 
> [1] http://www.openwall.com/lists/musl/2016/11/09/2
> [2] http://www.openwall.com/lists/musl/2016/11/11/1
> [3] http://www.openwall.com/lists/musl/2016/11/11/2

Thanks a lot for the explanation.

So I believe we should apply your proposed workaround. However, I'm not
sure I want to take the risk of applying this to the master branch
(even though I agree it could fix some build failures). Are you OK with
applying it to the next branch?

Then, the next step (which also worries me a little bit) is:

 1. Finding the packages that we have disabled for musl because of this
    header issue, and which should now be re-enabled in musl
    configurations.

 2. Finding the packages that have patches to fix this musl-related
    issue, and remove those patches (beyond the two specific packages
    for which you already take care of this as part of your series).

I'm not sure how to proceed to identify all the affected packages.

Thanks,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[Buildroot] [PATCH v2 1/3] toolchain: workaround musl/kernel headers conflict

[Baruch Siach]

Hi Thomas,

On Wed, Nov 16, 2016 at 04:55:57PM +0100, Thomas Petazzoni wrote:
> On Wed, 16 Nov 2016 17:45:16 +0200, Baruch Siach wrote:
> 
> > > Baruch, could you investigate whether this musl commit fixes the header
> > > conflict problem for bridge-utils and norm?  
> > 
> > The commit log links to this musl commit and to a mailing list report[1] that 
> > this fix is not enough on its own. As a result of this discussion Felix Janda 
> > posted a kernel patch[2] to address the issue. See also Rich's response[3]. 
> > Even if this patch is accepted, we'll most likely have to keep this 
> > workaround, or an equivalent, for as long as we support kernel headers v4.9 
> > and older.
> > 
> > [1] http://www.openwall.com/lists/musl/2016/11/09/2
> > [2] http://www.openwall.com/lists/musl/2016/11/11/1
> > [3] http://www.openwall.com/lists/musl/2016/11/11/2
> 
> Thanks a lot for the explanation.
> 
> So I believe we should apply your proposed workaround. However, I'm not
> sure I want to take the risk of applying this to the master branch
> (even though I agree it could fix some build failures). Are you OK with
> applying it to the next branch?

Of course. This is definitely not for master.

baruch

-- 
     http://baruch.siach.name/blog/                  ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch at tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -

[Buildroot] [PATCH v2 1/3] toolchain: workaround musl/kernel headers conflict

[Thomas Petazzoni]

Hello,

On Wed, 16 Nov 2016 18:25:20 +0200, Baruch Siach wrote:

> > So I believe we should apply your proposed workaround. However, I'm not
> > sure I want to take the risk of applying this to the master branch
> > (even though I agree it could fix some build failures). Are you OK with
> > applying it to the next branch?  
> 
> Of course. This is definitely not for master.

And any thoughts about my concerns to identify the packages that should
be re-enabled and patches that should be removed?

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[Buildroot] [PATCH v2 1/3] toolchain: workaround musl/kernel headers conflict

[Baruch Siach]

Hi Thomas,

On Wed, Nov 16, 2016 at 05:36:05PM +0100, Thomas Petazzoni wrote:
> On Wed, 16 Nov 2016 18:25:20 +0200, Baruch Siach wrote:
> 
> > > So I believe we should apply your proposed workaround. However, I'm not
> > > sure I want to take the risk of applying this to the master branch
> > > (even though I agree it could fix some build failures). Are you OK with
> > > applying it to the next branch?  
> > 
> > Of course. This is definitely not for master.
> 
> And any thoughts about my concerns to identify the packages that should
> be re-enabled and patches that should be removed?

Over time as packages get version bumps we'll have the chance to revise musl 
patches. Patches that cleanly apply to newer versions should not bother us, 
since they don't add maintenance burden.

As for !BR2_TOOLCHAIN_USES_MUSL dependencies, anyone interested in having a 
specific package building with musl may revise these dependences. Any typical 
package version bump sometimes makes dependencies removal possible, but it's 
not always apparent at bump time.

That being said, there are some low hanging fruits here that I plan to pick as 
time allows.

baruch

-- 
     http://baruch.siach.name/blog/                  ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch at tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -

[Buildroot] [PATCH v2 1/3] toolchain: workaround musl/kernel headers conflict

[Thomas Petazzoni]

Hello,

On Thu, 10 Nov 2016 15:27:11 +0200, Baruch Siach wrote:
> 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>
> ---
> v2:
>   * Add Rick's explanation in the commit log (Arnout)
>   * Link to more recent upstream changes
> ---
>  toolchain/toolchain/toolchain.mk | 14 ++++++++++++++
>  1 file changed, 14 insertions(+)

Series applied to the next branch. Thanks!

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [PATCH v2 1/3] toolchain: workaround musl/kernel headers conflict

[Thomas Petazzoni]

Hello Baruch,

I'm reviving this old thread, because my colleague Florent (in Cc) has
found an issue with this patch.

On Thu, 10 Nov 2016 15:27:11 +0200, Baruch Siach wrote:

> +# [1] http://www.openwall.com/lists/musl/2015/10/08/2
> +ifeq ($(BR2_TOOLCHAIN_USES_MUSL),y)
> +define TOOLCHAIN_MUSL_KERNEL_HEADERS_COMPATIBILITY_HACK
> +	$(SED) 's/^#if defined(__GLIBC__)$$/#if 1/' \
> +		$(STAGING_DIR)/usr/include/linux/libc-compat.h
> +endef

The problem with this is that libc-compat.h was introduced only in
kernel 3.12 (it seems). Therefore, trying to build a musl toolchain
with kernel headers 3.10 currently fails, with this $(SED) command
failing because $(STAGING_DIR)/usr/include/linux/libc-compat.h does not
exist.

So, we could add a kernel headers >= 3.12 to the condition to make the
build work, but then we wouldn't have the fix that these modifications
provide to avoid conflicts between libc and kernel headers.

Do you know if kernel headers < 3.12 are unaffected by the libc/kernel
headers conflict issue? If they are, do you know what the solution is
for kernel headers < 3.12 ?

Thanks!

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[Buildroot] [PATCH v2 1/3] toolchain: workaround musl/kernel headers conflict

[Baruch Siach]

Hi Thomas,

On Wed, May 17, 2017 at 03:33:53PM +0200, Thomas Petazzoni wrote:
> I'm reviving this old thread, because my colleague Florent (in Cc) has
> found an issue with this patch.
> 
> On Thu, 10 Nov 2016 15:27:11 +0200, Baruch Siach wrote:
> 
> > +# [1] http://www.openwall.com/lists/musl/2015/10/08/2
> > +ifeq ($(BR2_TOOLCHAIN_USES_MUSL),y)
> > +define TOOLCHAIN_MUSL_KERNEL_HEADERS_COMPATIBILITY_HACK
> > +	$(SED) 's/^#if defined(__GLIBC__)$$/#if 1/' \
> > +		$(STAGING_DIR)/usr/include/linux/libc-compat.h
> > +endef
> 
> The problem with this is that libc-compat.h was introduced only in
> kernel 3.12 (it seems). Therefore, trying to build a musl toolchain
> with kernel headers 3.10 currently fails, with this $(SED) command
> failing because $(STAGING_DIR)/usr/include/linux/libc-compat.h does not
> exist.
> 
> So, we could add a kernel headers >= 3.12 to the condition to make the
> build work, but then we wouldn't have the fix that these modifications
> provide to avoid conflicts between libc and kernel headers.
> 
> Do you know if kernel headers < 3.12 are unaffected by the libc/kernel
> headers conflict issue? If they are, do you know what the solution is
> for kernel headers < 3.12 ?

I have not tested kernel headers earlier than v3.12. Having a look at the 
headers and the log of kernel commit cfd280c91253cc28 (net: sync some IP 
headers with glibc), I'm pretty sure that the same issue also affects older 
kernels.

Should we just disallow build of musl toolchain with older kernels? Something 
like:

diff --git a/toolchain/toolchain-buildroot/Config.in b/toolchain/toolchain-buildroot/Config.in
index 91cddc237429..396f6d8ec2a5 100644
--- a/toolchain/toolchain-buildroot/Config.in
+++ b/toolchain/toolchain-buildroot/Config.in
@@ -74,6 +74,8 @@ config BR2_TOOLCHAIN_BUILDROOT_MUSL
 	# sh2 nommu is supported by musl, but we don't have support
 	# for it in Buildroot.
 	depends on BR2_USE_MMU
+	# We need the kernel libc-compat.h header
+	depends on BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_12
 	select BR2_TOOLCHAIN_USES_MUSL
 	help
 	  This option selects musl as the C library for the

baruch

-- 
     http://baruch.siach.name/blog/                  ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch@tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -

[Buildroot] [PATCH v2 1/3] toolchain: workaround musl/kernel headers conflict

[Thomas Petazzoni]

Hello,

On Thu, 18 May 2017 07:57:54 +0300, Baruch Siach wrote:

> I have not tested kernel headers earlier than v3.12. Having a look at the 
> headers and the log of kernel commit cfd280c91253cc28 (net: sync some IP 
> headers with glibc), I'm pretty sure that the same issue also affects older 
> kernels.
> 
> Should we just disallow build of musl toolchain with older kernels? Something 
> like:

That's one option, though a bit annoying, no? Just for this "small"
reason, we prevent people from using musl toolchains on kernels older
than 3.12 ?

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[Buildroot] [PATCH v2 1/3] toolchain: workaround musl/kernel headers conflict

[Baruch Siach]

Hi Thomas,

On Thu, May 18, 2017 at 09:10:30AM +0200, Thomas Petazzoni wrote:
> On Thu, 18 May 2017 07:57:54 +0300, Baruch Siach wrote:
> 
> > I have not tested kernel headers earlier than v3.12. Having a look at the 
> > headers and the log of kernel commit cfd280c91253cc28 (net: sync some IP 
> > headers with glibc), I'm pretty sure that the same issue also affects older 
> > kernels.
> > 
> > Should we just disallow build of musl toolchain with older kernels? Something 
> > like:
> 
> That's one option, though a bit annoying, no? Just for this "small"
> reason, we prevent people from using musl toolchains on kernels older
> than 3.12 ?

Would that be better (untested)?

diff --git a/toolchain/toolchain/toolchain.mk b/toolchain/toolchain/toolchain.mk
index e29837357a27..e15ceeb426fa 100644
--- a/toolchain/toolchain/toolchain.mk
+++ b/toolchain/toolchain/toolchain.mk
@@ -21,8 +21,10 @@ TOOLCHAIN_ADD_TOOLCHAIN_DEPENDENCY = NO
 # 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.
+#
 # [1] http://www.openwall.com/lists/musl/2015/10/08/2
-ifeq ($(BR2_TOOLCHAIN_USES_MUSL),y)
+ifeq ($(BR2_TOOLCHAIN_USES_MUSL)$(BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_12),yy)
 define TOOLCHAIN_MUSL_KERNEL_HEADERS_COMPATIBILITY_HACK
 	$(SED) 's/^#if defined(__GLIBC__)$$/#if 1/' \
 		$(STAGING_DIR)/usr/include/linux/libc-compat.h

baruch

-- 
     http://baruch.siach.name/blog/                  ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch at tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -

[Buildroot] [PATCH v2 1/3] toolchain: workaround musl/kernel headers conflict

[Thomas Petazzoni]

Hello,

On Thu, 18 May 2017 14:17:44 +0300, Baruch Siach wrote:

> Would that be better (untested)?
> 
> diff --git a/toolchain/toolchain/toolchain.mk b/toolchain/toolchain/toolchain.mk
> index e29837357a27..e15ceeb426fa 100644
> --- a/toolchain/toolchain/toolchain.mk
> +++ b/toolchain/toolchain/toolchain.mk
> @@ -21,8 +21,10 @@ TOOLCHAIN_ADD_TOOLCHAIN_DEPENDENCY = NO
>  # 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.
> +#
>  # [1] http://www.openwall.com/lists/musl/2015/10/08/2
> -ifeq ($(BR2_TOOLCHAIN_USES_MUSL),y)
> +ifeq ($(BR2_TOOLCHAIN_USES_MUSL)$(BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_12),yy)
>  define TOOLCHAIN_MUSL_KERNEL_HEADERS_COMPATIBILITY_HACK
>  	$(SED) 's/^#if defined(__GLIBC__)$$/#if 1/' \
>  		$(STAGING_DIR)/usr/include/linux/libc-compat.h

Yes. The question is whether we will see those build failures due to
kernel/userspace headers conflicts. Do you remember a simple
package/scenario that triggers the problem?

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[Buildroot] [PATCH v2 1/3] toolchain: workaround musl/kernel headers conflict

[Baruch Siach]

Hi Thomas,

On Thu, May 18, 2017 at 01:24:48PM +0200, Thomas Petazzoni wrote:
> On Thu, 18 May 2017 14:17:44 +0300, Baruch Siach wrote:
> > Would that be better (untested)?
> > 
> > diff --git a/toolchain/toolchain/toolchain.mk b/toolchain/toolchain/toolchain.mk
> > index e29837357a27..e15ceeb426fa 100644
> > --- a/toolchain/toolchain/toolchain.mk
> > +++ b/toolchain/toolchain/toolchain.mk
> > @@ -21,8 +21,10 @@ TOOLCHAIN_ADD_TOOLCHAIN_DEPENDENCY = NO
> >  # 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.
> > +#
> >  # [1] http://www.openwall.com/lists/musl/2015/10/08/2
> > -ifeq ($(BR2_TOOLCHAIN_USES_MUSL),y)
> > +ifeq ($(BR2_TOOLCHAIN_USES_MUSL)$(BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_12),yy)
> >  define TOOLCHAIN_MUSL_KERNEL_HEADERS_COMPATIBILITY_HACK
> >  	$(SED) 's/^#if defined(__GLIBC__)$$/#if 1/' \
> >  		$(STAGING_DIR)/usr/include/linux/libc-compat.h
> 
> Yes. The question is whether we will see those build failures due to
> kernel/userspace headers conflicts. Do you remember a simple
> package/scenario that triggers the problem?

The following two commits in this series, c0b756cac412 (Revert "bridge-utils: 
fix build with musl"), and bae792e4c04 (Revert "norm: add patch to fix musl 
build"), point at some likely build failure candidates.

baruch

-- 
     http://baruch.siach.name/blog/                  ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch at tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -