[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <48ff14c5fff0af909519619caa26d20fcda5159c.camel@gmail.com>
Date: Wed, 02 Jun 2021 13:46:32 -0500
From: Andreas Roeseler <andreas.a.roeseler@...il.com>
To: Florian Weimer <fweimer@...hat.com>
Cc: netdev@...r.kernel.org, davem@...emloft.net,
yoshfuji@...ux-ipv6.org, dsahern@...nel.org, kuba@...nel.org
Subject: Re: [PATCH net-next V6 1/6] icmp: add support for RFC 8335 PROBE
On Wed, 2021-06-02 at 19:58 +0200, Florian Weimer wrote:
> * Andreas Roeseler:
>
> > diff --git a/include/uapi/linux/icmp.h b/include/uapi/linux/icmp.h
> > index fb169a50895e..222325d1d80e 100644
> > --- a/include/uapi/linux/icmp.h
> > +++ b/include/uapi/linux/icmp.h
> > @@ -20,6 +20,9 @@
> >
> > #include <linux/types.h>
> > #include <asm/byteorder.h>
> > +#include <linux/in.h>
> > +#include <linux/if.h>
> > +#include <linux/in6.h>
>
> We have received a report that this breaks compiliation of trinity
> because it includes <netinet/in.h> and <linux/icmp.h> at the same
> time,
> and there is no multiple-definition guard for struct in_addr and
> other
> definitions:
>
> In file included from include/net.h:5,
> from net/proto-ip-raw.c:2:
> /usr/include/netinet/in.h:31:8: error: redefinition of ‘struct
> in_addr’
> 31 | struct in_addr
> | ^~~~~~~
> In file included from /usr/include/linux/icmp.h:23,
> from net/proto-ip-raw.c:1:
> /usr/include/linux/in.h:89:8: note: originally defined here
> 89 | struct in_addr {
> | ^~~~~~~
> In file included from /usr/include/netinet/in.h:37,
> from include/net.h:5,
> from net/proto-ip-raw.c:2:
> /usr/include/bits/in.h:150:8: error: redefinition of ‘struct
> ip_mreqn’
> 150 | struct ip_mreqn
> | ^~~~~~~~
> In file included from /usr/include/linux/icmp.h:23,
> from net/proto-ip-raw.c:1:
> /usr/include/linux/in.h:178:8: note: originally defined here
> 178 | struct ip_mreqn {
> | ^~~~~~~~
>
> (More conflicts appear to follow.)
>
> I do not know what the correct way forward is. Adding the
> multiple-definition guards is quite a bit of work and requires
> updates
> in glibc and the kernel to work properly.
>
> Thanks,
> Florian
>
Are <netinet/in.h> and <linux/in.h> the only conflicting files?
<linux/in.h> is only included to gain use of the in_addr struct, but
that can be easily substituted out of the code in favor of __be32.
Therefore we would no longer need to include <linux/in.h> and would
remove the conflict.
Powered by blists - more mailing lists