DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Smoczynski, MarcinX" <marcinx.smoczynski@intel.com>
To: "Richardson, Bruce" <bruce.richardson@intel.com>,
	"thomas@monjalon.net" <thomas@monjalon.net>
Cc: "dev@dpdk.org" <dev@dpdk.org>,
	"Ananyev, Konstantin" <konstantin.ananyev@intel.com>,
	"shahafs@mellanox.com" <shahafs@mellanox.com>,
	"gaetan.rivet@6wind.com" <gaetan.rivet@6wind.com>
Subject: [dpdk-dev] Using _XOPEN_SOURCE macros may break builds on FreeBSD
Date: Fri, 10 May 2019 17:14:44 +0000	[thread overview]
Message-ID: <2F25558C1648FA498380EAC12A8612624FD953@HASMSX110.ger.corp.intel.com> (raw)
Message-ID: <20190510171444.K5see3_eEjUVCLULFE3WRsbLgqr2hIx8tkc4SWRbj8M@z> (raw)

Hi.
One of my patches submitted this week is breaking build on BSD systems. I dug
deeper and found out that it's because I'm using IPPROTO_* macros from
<netinet/in.h> in a header (rte_ip.h) which is included in the driver which uses
_XOPEN_SOURCE definition in its Makefile/meson.build.

On Linux and glibc this is not a problem, because:
1. Those IPPROTO macros are included unconditionally and
2. We're using _GNU_SOURCE at top level anyway which gives us visibility of
   every feature set. According to "features.h" from glibc 2.18
   (used in Ubuntu 18.04):

   https://github.molgen.mpg.de/git-mirror/glibc/blob/release/2.18/master/include/features.h
     /* If _GNU_SOURCE was defined by the user, turn on all the other features.  */
     #ifdef _GNU_SOURCE
     # undef  _ISOC95_SOURCE
     # define _ISOC95_SOURCE    1
     # undef  _ISOC99_SOURCE
     # define _ISOC99_SOURCE    1
     # undef  _ISOC11_SOURCE
     # define _ISOC11_SOURCE    1
     # undef  _POSIX_SOURCE
     # define _POSIX_SOURCE     1
     # undef  _POSIX_C_SOURCE
     # define _POSIX_C_SOURCE   200809L
     # undef  _XOPEN_SOURCE
     # define _XOPEN_SOURCE     700
     # undef  _XOPEN_SOURCE_EXTENDED
     # define _XOPEN_SOURCE_EXTENDED 1
     # undef    _LARGEFILE64_SOURCE
     # define _LARGEFILE64_SOURCE    1
     # undef  _BSD_SOURCE
     # define _BSD_SOURCE 1
     # undef  _SVID_SOURCE
     # define _SVID_SOURCE 1
     # undef  _ATFILE_SOURCE
     # define _ATFILE_SOURCE    1
     #endif

BSD systems are a little bit more orthodox:
1. IPPROTOs are defined conditionally if __BSD_VISIBLE macro is defined. If I
   understand it correctly, they are not a part of any POSIX specification
   and that's why they are kept separated.
2. __BSD_VISIBLE is set to 0 if any of XOPEN_SOURCE or POSIX_C_SOURCE macros
   are defined. The reasoning here is: if you don't specify feature set you want
   to use you have it all, but when you do, you have exactly what you've
   explicitly asked for. Using XOPEN_SOURCE=700 means: give me POSIX 2k8 and
   XSI only. In other words using this macro alone is restricting portability;
   by default DPDK is building with full visibility.

   https://github.com/freebsd/freebsd/blob/release/12.0.0/sys/sys/cdefs.h
   Lines 680 to 765
     /* Deal with various X/Open Portability Guides and Single UNIX Spec. */
     #ifdef _XOPEN_SOURCE
     #if _XOPEN_SOURCE - 0 >= 700
     #define    __XSI_VISIBLE        700
     #undef _POSIX_C_SOURCE
     #define    _POSIX_C_SOURCE      200809
     #elif _XOPEN_SOURCE - 0 >= 600
     #define    __XSI_VISIBLE        600
     #undef _POSIX_C_SOURCE
     #define    _POSIX_C_SOURCE      200112
     #elif _XOPEN_SOURCE - 0 >= 500
     #define    __XSI_VISIBLE        500
     #undef _POSIX_C_SOURCE
     #define    _POSIX_C_SOURCE      199506
     #endif
     #endif

     /*
     * Deal with all versions of POSIX.  The ordering relative to the tests above is
     * important.
     */
     #if defined(_POSIX_SOURCE) && !defined(_POSIX_C_SOURCE)
     #define    _POSIX_C_SOURCE      198808
     #endif
     #ifdef _POSIX_C_SOURCE
     #if _POSIX_C_SOURCE >= 200809
     #define    __POSIX_VISIBLE      200809
     #define    __ISO_C_VISIBLE      1999
     #elif _POSIX_C_SOURCE >= 200112
     #define    __POSIX_VISIBLE      200112
     #define    __ISO_C_VISIBLE      1999
     #elif _POSIX_C_SOURCE >= 199506
     #define    __POSIX_VISIBLE      199506
     #define    __ISO_C_VISIBLE      1990
     #elif _POSIX_C_SOURCE >= 199309
     #define    __POSIX_VISIBLE      199309
     #define    __ISO_C_VISIBLE      1990
     #elif _POSIX_C_SOURCE >= 199209
     #define    __POSIX_VISIBLE      199209
     #define    __ISO_C_VISIBLE      1990
     #elif _POSIX_C_SOURCE >= 199009
     #define    __POSIX_VISIBLE      199009
     #define    __ISO_C_VISIBLE      1990
     #else
     #define    __POSIX_VISIBLE      198808
     #define    __ISO_C_VISIBLE      0
     #endif /* _POSIX_C_SOURCE */
     #else                <----- !!!
     /*-
     * Deal with _ANSI_SOURCE:
     * If it is defined, and no other compilation environment is explicitly
     * requested, then define our internal feature-test macros to zero.  This
     * makes no difference to the preprocessor (undefined symbols in preprocessing
     * expressions are defined to have value zero), but makes it more convenient for
     * a test program to print out the values.
     *
     * If a program mistakenly defines _ANSI_SOURCE and some other macro such as
     * _POSIX_C_SOURCE, we will assume that it wants the broader compilation
     * environment (and in fact we will never get here).
     */
     #if defined(_ANSI_SOURCE)  /* Hide almost everything. */
     #define    __POSIX_VISIBLE      0
     #define    __XSI_VISIBLE        0
     #define    __BSD_VISIBLE        0
     #define    __ISO_C_VISIBLE      1990
     #define    __EXT1_VISIBLE       0
     #elif defined(_C99_SOURCE) /* Localism to specify strict C99 env. */
     #define    __POSIX_VISIBLE      0
     #define    __XSI_VISIBLE        0
     #define    __BSD_VISIBLE        0
     #define    __ISO_C_VISIBLE      1999
     #define    __EXT1_VISIBLE       0
     #elif defined(_C11_SOURCE) /* Localism to specify strict C11 env. */
     #define    __POSIX_VISIBLE      0
     #define    __XSI_VISIBLE        0
     #define    __BSD_VISIBLE        0
     #define    __ISO_C_VISIBLE      2011
     #define    __EXT1_VISIBLE       0
     #else                /* Default environment: show everything. */

     By default DPDK falls here:

     #define    __POSIX_VISIBLE      200809
     #define    __XSI_VISIBLE        700
     #define    __BSD_VISIBLE        1
     #define    __ISO_C_VISIBLE      2011
     #define    __EXT1_VISIBLE       1
     #endif
     #endif

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) or add explicit -D__BSD_VISIBLE when
building for BSD. I think also that defining _GNU_SOURCE for BSD builds makes no
sense although it does not cause any problems.

I have checked that removing those problematic macros solves build problems on
FreeBSD12 and does not break on Ubuntu 18.04.

I'd appreciate your thoughts on this topic.

Regards, Marcin.

             reply	other threads:[~2019-05-10 17:14 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-10 17:14 Smoczynski, MarcinX [this message]
2019-05-10 17:14 ` Smoczynski, MarcinX
2019-05-10 18:17 ` Thomas Monjalon
2019-05-10 18:17   ` Thomas Monjalon
2019-05-10 18:23   ` Thomas Monjalon
2019-05-10 18:23     ` Thomas Monjalon
2019-05-13  9:51     ` Smoczynski, MarcinX
2019-05-13  9:51       ` Smoczynski, MarcinX
2019-05-13 10:25       ` Adrien Mazarguil
2019-05-13 10:25         ` Adrien Mazarguil
2019-05-13 10:49         ` Ananyev, Konstantin
2019-05-13 10:49           ` Ananyev, Konstantin
2019-05-13 13:14           ` Adrien Mazarguil
2019-05-13 13:14             ` Adrien Mazarguil
2019-05-13 16:24             ` Ananyev, Konstantin
2019-05-13 16:24               ` Ananyev, Konstantin
2019-05-14  8:58               ` Smoczynski, MarcinX
2019-05-14  8:58                 ` Smoczynski, MarcinX
2019-05-14  9:16                 ` Adrien Mazarguil
2019-05-14  9:16                   ` Adrien Mazarguil
2019-05-14 10:29                   ` Ananyev, Konstantin
2019-05-14 10:29                     ` Ananyev, Konstantin

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=2F25558C1648FA498380EAC12A8612624FD953@HASMSX110.ger.corp.intel.com \
    --to=marcinx.smoczynski@intel.com \
    --cc=bruce.richardson@intel.com \
    --cc=dev@dpdk.org \
    --cc=gaetan.rivet@6wind.com \
    --cc=konstantin.ananyev@intel.com \
    --cc=shahafs@mellanox.com \
    --cc=thomas@monjalon.net \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).