Build on ubuntu 12.04 fails with "error: redefinition of struct in6_addr" about libnl HOT 8 CLOSED

I'm getting a similar failure:

In file included from ../libnl-3.3.0/include/linux-private/linux/ipv6.h:5:0,
                 from ../libnl-3.3.0/include/netlink-private/netlink.h:54,
                 from ../libnl-3.3.0/lib/nl.c:28:
../libnl-3.3.0/include/linux-private/linux/in6.h:32:8: error: redefinition of 'struct in6_addr'
 struct in6_addr {
        ^~~~~~~~

In file included from TOPDIR/tmp/work/i586-poky-linux-musl/libnl/1_3.3.0-r0/recipe-sysroot/usr/include/arpa/inet.h:9:0,
                 from ../libnl-3.3.0/include/netlink-private/netlink.h:32,
                 from ../libnl-3.3.0/lib/nl.c:28:
TOPDIR/tmp/work/i586-poky-linux-musl/libnl/1_3.3.0-r0/recipe-sysroot/usr/include/netinet/in.h:23:8: note: originally defined here
 struct in6_addr {
        ^~~~~~~~

from libnl.

on plain Ubuntu 12.04.5 I was unable to reproduce this. Seems you are using musl.

Note, that nowadays glibc and kernel headers are synchronized so that you can include in.h from glibc/kernel in either order.

I think this is a libc/kernel bug.

Since it doesn't happen for me, I dunno how to work around it. Patches welcome though.

from libnl.

This problem seems to be described in the musl-libc wiki. A workaround is removing the #include <linux/in6.h> from include/linux-private/linux/ipv6.h and include/linux-private/linux/if_bridge.h.

The change that caused it is probably 6c7f421, although I haven't tested this theory. The relevant changes in the "sanitized" headers seem to be sabotage-linux/kernel-headers@3cd5b95.

I'm not really sure what a proper fix would be - any thoughts?

from libnl.

Thanks for looking into this, @hobbitalastair, your information was very useful.

Looks like the gentoo-musl folks discussed this a bit (gentoo/musl#32), and the the patch from their tree seems to resolve this issue for me on 3.3.0 at least.

I'm not sure if this is suitable for inclusion in the project or not but hope this helps!

from libnl.

Since linux commit c0bace7984, included in 4.15, kernel and musl headers work much better together.

I think all that is necessary to resolve this is to sync the kernel headers to newer versions. I had a go at updating to v4.19 headers (the current longterm version) in my branch master...michaelforney:linux-headers. This fixes the build with musl, and will allow all musl-based distributions to drop the patches they've been carrying.

I did hit a couple snags:

• TCF_META_ID_SK_ROUTE_CAPS is renamed to __TCF_META_ID_SK_ROUTE_CAPS, with the comment "unimplemented but in ABI already".
• The header linux/ip_mp_alg.h does not seem to exist (did it ever? I can't find a trace of it in the linux git repository). However, the last reference to the constants it provides was removed in 535e831.
• The IF_CARRIER_DOWN and IF_CARRIER_UP constants don't exist in linux/if.h. Again, I can't find traces of them in the linux git repository, so I just replaced them with their values, 0 and 1.

from libnl.

The discussion about supported libcs seems mostly distinct from supported compilers...

Re: our kernel headers in include/linux-private. I think we should just regularly re-import them all from the latest kernel release (with a mindless script). These headers (and kernel's user-space API) are anyway supposed to be backward compatible, so this should cause no problems (in theory :) ).

Patch welcome, or I'll do it one of these days.

• preferably pick the kernel headers from a real release (not from master branch)
• preferably import them in a fully automated manner without manual modifications.

from libnl.

The discussion about supported libcs seems mostly distinct from supported compilers...

Yes, this is a separate issue. Didn't mean for it to get confused with the discussion for my previous pull request.

Patch welcome, or I'll do it one of these days.

• preferably pick the kernel headers from a real release (not from master branch)
• preferably import them in a fully automated manner without manual modifications.

This is what I did in the branch I mentioned above. I turned it into pull request #222.

from libnl.

The discussion about supported libcs seems mostly distinct from supported compilers...

Yes, this is a separate issue. Didn't mean for it to get confused with the discussion for my previous pull request.

I actually confused it, that why this comment of mine makes no sense :)

I think with #222 merged, this can be closed as fixed. Or are there some missing issues? If so, please reopen. Thanks.

from libnl.