PATCH] Revert "bridge: include in6.h in if_bridge.h for struct in6_addr"
Subsystems (3)
This reverts commit 66f1c44887ba4f47d617f8ae21cf8e04e1892bd7.
iproute2 uses sanitized kernel headers, and this change broke the build. The problem is that the iproute2 ip/iplink_bridge_slave.c include if_bridge.h but this causes a redefintion error when Glibc <netlink/in.h> is included.
Since iproute2 is arguably the most important user of network headers, the uapi header change should be reverted.
---
Please update stable as well.
include/uapi/linux/if_bridge.h | 1 - 1 file changed, 1 deletion(-)
include/uapi/linux/if_bridge.h +0 -1
@@ -15,7 +15,6 @@#include <linux/types.h> #include <linux/if_ether.h> -#include <linux/in6.h> #define SYSFS_BRIDGE_ATTR "bridge"#define SYSFS_BRIDGE_FDB "brforward"
Signature · 1 line
2.1.3
David Miller
maintainerFrom: Stephen Hemminger <[email protected]>
Date: Tue, 9 Dec 2014 20:30:07 -0800
Quoted 10 lines
This reverts commit
66f1c44887ba4f47d617f8ae21cf8e04e1892bd7.iproute2 uses sanitized kernel headers, and this change broke the build. The problem is that the iproute2
ip/iplink_bridge_slave.cincludeif_bridge.hbut this causes a redefintion error when Glibc <netlink/in.h> is included.Since iproute2 is arguably the most important user of network headers, the uapi header change should be reverted.
Signed-off-by Stephen Hemminger <[email protected]>
Stephen, please understand first the reason for this change.
GLIBC and the kernel fight over various definitions of core networking types.
The only way to resolve this in the long term is this change in question.
If you can make iproute2 work with both the new and the old mechanims, please do so instead of reverting this important change.
PATCH v2 1/1 if_bridge: fix conflict with glibc
Even though kernel and glibc headers have same effective values Gcc complains about redefinitions. Since this is a header expected to be used by userspace, use glibc header.
This supersedes change in commit 66f1c44887ba4f47d617f8ae21cf8e04e1892bd7 and fixes build of iproute2 with Glibc-2.19. This follows similar usage in include/uapi/linux for l2tp.h
include/uapi/linux/if_bridge.h +3 -1
@@ -15,7 +15,9 @@#include <linux/types.h> #include <linux/if_ether.h> -#include <linux/in6.h> +#ifndef __KERNEL__ +#include <netinet/in.h> +#endif #define SYSFS_BRIDGE_ATTR "bridge"#define SYSFS_BRIDGE_FDB "brforward"
David Miller
maintainerRe: [PATCH v2] if_bridge: fix conflict with glibc
From: Stephen Hemminger <[email protected]>
Date: Tue, 9 Dec 2014 21:41:22 -0800
Quoted 13 lines
Even though kernel and glibc headers have same effective values Gcc complains about redefinitions. Since this is a header expected to be used by userspace, use glibc header.
This supersedes change in commit
66f1c44887ba4f47d617f8ae21cf8e04e1892bd7and fixes build of iproute2 with Glibc-2.19. This follows similar usage ininclude/uapi/linuxforl2tp.hSigned-off-by Stephen Hemminger <[email protected]>
include/uapi/linux/if_bridge.h line 20
Quoted 7 lines
include/uapi/linux/if_bridge.h +3
-1@@ -15,7 +15,9 @@#include <linux/types.h> #include <linux/if_ether.h> -#include <linux/in6.h> +#ifndef __KERNEL__ +#include <netinet/in.h> +#endif
No, we really want to incluse the linux/in6.h header, as that's where all the special GLIBC CPP checks are, such as:
#if __UAPI_DEF_IN6_ADDR_ALT
Please research how we have resolved the conflict between GLIBC and the kernel's exported headers. We really need to use linux/in6.h for all of this to work.
I understand that it is upsetting that iproute2 stopped building for you, but I'd like to kindly ask that you look more deeply into this and think more longer term, rather than having a knee jerk reaction and looking for quick fixes.
Thanks.
Re: [PATCH v2] if_bridge: fix conflict with glibc
Quoted 29 lines · On Wed, 10 Dec 2014 13:34:17 -0500 (EST) David Miller <[email protected]>…
From: Stephen Hemminger <[email protected]>
Date: Tue, 9 Dec 2014 21:41:22 -0800Quoted 13 lines
Even though kernel and glibc headers have same effective values Gcc complains about redefinitions. Since this is a header expected to be used by userspace, use glibc header.
This supersedes change in commit
66f1c44887ba4f47d617f8ae21cf8e04e1892bd7and fixes build of iproute2 with Glibc-2.19. This follows similar usage ininclude/uapi/linuxforl2tp.hSigned-off-by Stephen Hemminger <[email protected]>include/uapi/linux/if_bridge.h line 20
Quoted 7 lines
include/uapi/linux/if_bridge.h +3
-1@@ -15,7 +15,9 @@#include <linux/types.h> #include <linux/if_ether.h> -#include <linux/in6.h> +#ifndef __KERNEL__ +#include <netinet/in.h> +#endif No, we really want to incluse the
linux/in6.hheader, as that's where all the special GLIBC CPP checks are, such as:#if
__UAPI_DEF_IN6_ADDR_ALT
Quoted 8 lines
Please research how we have resolved the conflict between GLIBC and the kernel's exported headers. We really need to use
linux/in6.hfor all of this to work.I understand that it is upsetting that iproute2 stopped building for you, but I'd like to kindly ask that you look more deeply into this and think more longer term, rather than having a knee jerk reaction and looking for quick fixes.
I don't have the time to understand the intricacies of glibc headers. The problem is that Gcc warns about duplicate definitions in headers; this is a useful warning and not something that I want to disable. Hacks with #undef seem to be heading the wrong way.
David Miller
maintainerRe: [PATCH v2] if_bridge: fix conflict with glibc
From: Stephen Hemminger <[email protected]>
Date: Wed, 10 Dec 2014 15:57:45 -0800
Quoted 17 lines
Quoted 5 lines · On Wed, 10 Dec 2014 13:34:17 -0500 (EST) David Miller <[email protected]>…
No, we really want to incluse the
linux/in6.hheader, as that's where all the special GLIBC CPP checks are, such as:#if
__UAPI_DEF_IN6_ADDR_ALTQuoted 8 lines
Please research how we have resolved the conflict between GLIBC and the kernel's exported headers. We really need to use
linux/in6.hfor all of this to work.I understand that it is upsetting that iproute2 stopped building for you, but I'd like to kindly ask that you look more deeply into this and think more longer term, rather than having a knee jerk reaction and looking for quick fixes.
Quoted 4 lines
I don't have the time to understand the intricacies of glibc headers. The problem is that Gcc warns about duplicate definitions in headers; this is a useful warning and not something that I want to disable. Hacks with #undef seem to be heading the wrong way.
GLIBC and the kernel have unconditionally defined various types in their copies of in.h, and the only way to resolve this moving forward is to have some communication between the two so we can know who is in fact in charge of instantianting the type.
The new defines, such as __UAPI_DEF_IN6_ADDR_ALT, are that new mechanism.