[dpdk-dev] Using _XOPEN_SOURCE macros may break builds on FreeBSD

Adrien Mazarguil adrien.mazarguil at 6wind.com
Mon May 13 12:25:10 CEST 2019

On Mon, May 13, 2019 at 09:51:24AM +0000, Smoczynski, MarcinX wrote:
> 10/05/2019 20:17, Thomas Monjalon:
> > 10/05/2019 19:14, Smoczynski, MarcinX:
> > > To summarize we have different visibility sets for Linux and BSD 
> > > when using XOPEN_SOURCE or POSIX_C_SOURCE explicitly. To overcome 
> > > this situation we can either remove problematic XOPEN macros from 
> > > mk/meson rules (drivers/net/failsafe, drivers/net/mlx4, 
> > > drivers/net/mlx5)
> > 
> > What is the consequence of removing these macros in mlx and failsafe PMDs?
> The purpose of these *_SOURCE constants is to enable particular feature sets
> visibility. As long as we have GNU_SOURCE on Linux removing it won't have any
> consequences. On BSD it will unify feature sets visibility with the rest of
> sources. Can't think of any downsides here.
> I believe XOPEN_SOURCE was introduced to extend features not to restrict them.

I confirm that under Linux, all IPPROTO_* (POSIX/XOPEN/RFC1700) are defined
regardless (_GNU_SOURCE not even needed), while under FreeBSD, the non-POSIX
versions are only defined when __BSD_VISIBLE is set.

The FreeBSD behavior is more correct in this respect since the purpose of
_XOPEN_SOURCE and friends is also to let applications limit the risk of
redefinitions in case they were written for an earlier standard
(e.g. -D_XOPEN_SOURCE=500 vs. -D_XOPEN_SOURCE=600).

DPDK applications may also define _XOPEN_SOURCE for their own needs. They
should still be able to use rte_ip.h afterward. I think this reason is
enough to go with -D__BSD_VISIBLE under FreeBSD without removing
_XOPEN_SOURCE, as it should work regardless.

Looking at the patch [1], I also think there's another, simpler approach:
unless really performance critical, defining rte_ipv6_get_next_ext() in
rte_net.c instead of a static inline in rte_ip.h should address this issue.

[1] "[PATCH 1/3] net: new ipv6 header extension parsing function"

Adrien Mazarguil

More information about the dev mailing list