From: Pablo Neira Ayuso <pablo@netfilter.org>
To: Phil Sutter <phil@nwl.cc>, Alyssa Ross <hi@alyssa.is>,
netfilter-devel@vger.kernel.org,
Joshua Lant <joshualant@googlemail.com>
Subject: Re: [PATCH nftables] include: fix for musl with iptables v1.8.11
Date: Thu, 9 Jan 2025 00:34:01 +0100 [thread overview]
Message-ID: <Z38Ladz49yJcTC8p@calendula> (raw)
In-Reply-To: <Z2VkJrkSLRmY9lAE@orbyte.nwl.cc>
Hi,
On Fri, Dec 20, 2024 at 01:33:42PM +0100, Phil Sutter wrote:
> On Fri, Dec 20, 2024 at 01:07:56PM +0100, Alyssa Ross wrote:
> > On Fri, Dec 20, 2024 at 12:50:42PM +0100, Phil Sutter wrote:
> > > Hi Alyssa,
> > >
> > > On Fri, Dec 20, 2024 at 12:10:02AM +0100, Alyssa Ross wrote:
> > > > Since iptables commit 810f8568 (libxtables: xtoptions: Implement
> > > > XTTYPE_ETHERMACMASK), nftables failed to build for musl libc:
> > > >
> > > > In file included from /nix/store/bvffdqfhyxvx66bqlqqdmjmkyklkafv6-musl-1.2.5-dev/include/netinet/et…
> > > > from /nix/store/kz6fymqpgbrj6330s6wv4idcf9pwsqs4-iptables-1.8.10-de…
> > > > from src/xt.c:30:
> > > > /nix/store/bvffdqfhyxvx66bqlqqdmjmkyklkafv6-musl-1.2.5-dev/include/netinet/if_ether.h:115:8: error: redefinition of 'struct ethhdr'
> > > > 115 | struct ethhdr {
> > > > | ^~~~~~
> > > > In file included from ./include/linux/netfilter_bridge.h:8,
> > > > from ./include/linux/netfilter_bridge/ebtables.h:1,
> > > > from src/xt.c:27:
> > > > /nix/store/bvffdqfhyxvx66bqlqqdmjmkyklkafv6-musl-1.2.5-dev/include/linux/if_ether.h:173:8: note: originally defined here
> > > > 173 | struct ethhdr {
> > > > | ^~~~~~
> > > >
> > > > The fix is to use libc's version of if_ether.h before any kernel
> > > > headers, which takes care of conflicts with the kernel's struct ethhdr
> > > > definition by defining __UAPI_DEF_ETHHDR, which will tell the kernel's
> > > > header not to define its own version.
> > >
> > > What I don't like about this is how musl tries to force projects to not
> > > include linux/if_ether.h directly. From the project's view, this is a
> > > workaround not a fix.
> >
> > My understanding is that it's a general principle of using any libc on
> > Linux that if there's both a libc and kernel header for the same thing,
> > the libc header should be used. libc headers will of course include
> > other libc headers in preference to kernel headers, so if you also
> > include the kernel headers you're likely to end up with conflicts.
> > Whether conflicts occur in any particular case depends on how a
> > particular libc chooses to expose a particular kernel API. I could be
> > misremembering, but I believe the same thing can happen with Glibc —
> > some headers under sys/ cause conflicts with their corresponding kernel
> > headers if both are included. While this case is musl specific, I
> > think the principle applies to all libcs.
>
> While this may be true for the vast majority of user space programs,
> netfilter tools and libraries are a bit special in how close they
> interface with the kernel. Not all netfilter-related kernel API is
> exposed by glibc, for instance. Including (some) kernel headers is
> therefore unavoidable, and (as your patch shows) order of inclusion
> becomes subtly relevant in ways which won't show when compile-testing
> against glibc only.
>
> > > > Signed-off-by: Alyssa Ross <hi@alyssa.is>
> > > > ---
> > > > A similar fix would solve the problem properly in iptables, which was
> > > > worked around with 76fce228 ("configure: Determine if musl is used for build").
> > > > The __UAPI_DEF_ETHHDR is supposed to be set by netinet/if_ether.h,
> > > > rather than manually by users.
> > >
> > > Why does 76fce228 not work for you?
> >
> > It does work, but that's a fix for iptables. This is a fix for
> > nftables. I could have submitted a copy of the iptables fix, but I
> > don't think it's the best fix due to its reliance on internal macros
> > that are not part of the public interface.
>
> Ah, sorry! Patch subject and description managed to confuse me.
>
> Pablo, what's your opinion? Maybe we should strive for the same solution
> for the problem in all netfilter user space, so either take what we have
> in iptables or adjust iptables to what nftables decides how things
> should be?
I see, you mean to use this (from iptables):
commit 76fce22826f8e860b5eb5b5a2463040c17ff85da
Author: Joshua Lant <joshualant@googlemail.com>
Date: Wed Aug 28 13:47:31 2024 +0100
configure: Determine if musl is used for build
and adapt to use it from nftables (and everywhere else).
Alyssa's patch is more simple, but it is mangling a cache kernel
header.
Is this configure.ac workaround needed everywhere in the netfilter.org
trees to make musl happy?
I don't see any better option at this stage.
Thanks.
next prev parent reply other threads:[~2025-01-08 23:34 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-19 23:10 [PATCH nftables] include: fix for musl with iptables v1.8.11 Alyssa Ross
2024-12-20 11:50 ` Phil Sutter
2024-12-20 12:07 ` Alyssa Ross
2024-12-20 12:33 ` Phil Sutter
2024-12-21 15:34 ` Alyssa Ross
2025-01-08 23:34 ` Pablo Neira Ayuso [this message]
2025-01-08 23:49 ` Phil Sutter
2025-01-09 0:03 ` Pablo Neira Ayuso
2025-01-09 10:02 ` Phil Sutter
2026-02-11 13:49 ` Florian Westphal
2026-02-11 18:59 ` Phil Sutter
2026-02-11 19:09 ` Florian Westphal
2026-02-11 20:19 ` Phil Sutter
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Z38Ladz49yJcTC8p@calendula \
--to=pablo@netfilter.org \
--cc=hi@alyssa.is \
--cc=joshualant@googlemail.com \
--cc=netfilter-devel@vger.kernel.org \
--cc=phil@nwl.cc \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.