From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by dpdk.space (Postfix) with ESMTP id A18D5A0096 for ; Fri, 10 May 2019 19:14:53 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 8693F2C18; Fri, 10 May 2019 19:14:51 +0200 (CEST) Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by dpdk.org (Postfix) with ESMTP id 135672B87 for ; Fri, 10 May 2019 19:14:49 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga104.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 May 2019 10:14:49 -0700 X-ExtLoop1: 1 Received: from fmsmsx106.amr.corp.intel.com ([10.18.124.204]) by orsmga005.jf.intel.com with ESMTP; 10 May 2019 10:14:48 -0700 Received: from fmsmsx154.amr.corp.intel.com (10.18.116.70) by FMSMSX106.amr.corp.intel.com (10.18.124.204) with Microsoft SMTP Server (TLS) id 14.3.408.0; Fri, 10 May 2019 10:14:47 -0700 Received: from lcsmsx152.ger.corp.intel.com (10.186.165.231) by FMSMSX154.amr.corp.intel.com (10.18.116.70) with Microsoft SMTP Server (TLS) id 14.3.408.0; Fri, 10 May 2019 10:14:47 -0700 Received: from HASMSX110.ger.corp.intel.com ([169.254.6.170]) by LCSMSX152.ger.corp.intel.com ([10.186.165.231]) with mapi id 14.03.0415.000; Fri, 10 May 2019 20:14:44 +0300 From: "Smoczynski, MarcinX" To: "Richardson, Bruce" , "thomas@monjalon.net" CC: "dev@dpdk.org" , "Ananyev, Konstantin" , "shahafs@mellanox.com" , "gaetan.rivet@6wind.com" Thread-Topic: Using _XOPEN_SOURCE macros may break builds on FreeBSD Thread-Index: AdUHUhFuf1vcUQd1TgeecdbKRnBo9Q== Date: Fri, 10 May 2019 17:14:44 +0000 Message-ID: <2F25558C1648FA498380EAC12A8612624FD953@HASMSX110.ger.corp.intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.600.7 dlp-reaction: no-action x-ctpclassification: CTP_NT x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiYTZmNmU4ZGQtYzI0MS00NjFkLTk5OWEtYTljMzA4NzMwOGFiIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiRFwvUjQweW1jT0l0WlZwTzF3QnNJM0VDMnpjS3hPbGpCc1BhMkNlaGlnb1dIMFdrYWVwUTkxR2lBejB6eUdrN3oifQ== x-originating-ip: [10.104.12.178] MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: [dpdk-dev] Using _XOPEN_SOURCE macros may break builds on FreeBSD X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Message-ID: <20190510171444.K5see3_eEjUVCLULFE3WRsbLgqr2hIx8tkc4SWRbj8M@z> Hi. One of my patches submitted this week is breaking build on BSD systems. I d= ug deeper and found out that it's because I'm using IPPROTO_* macros from 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/i= nclude/features.h /* If _GNU_SOURCE was defined by the user, turn on all the other featu= res. */ #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 macro= s 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=3D700 means: give me POSIX 2k8 = and XSI only. In other words using this macro alone is restricting portabili= ty; 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 >=3D 700 #define __XSI_VISIBLE 700 #undef _POSIX_C_SOURCE #define _POSIX_C_SOURCE 200809 #elif _XOPEN_SOURCE - 0 >=3D 600 #define __XSI_VISIBLE 600 #undef _POSIX_C_SOURCE #define _POSIX_C_SOURCE 200112 #elif _XOPEN_SOURCE - 0 >=3D 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 >=3D 200809 #define __POSIX_VISIBLE 200809 #define __ISO_C_VISIBLE 1999 #elif _POSIX_C_SOURCE >=3D 200112 #define __POSIX_VISIBLE 200112 #define __ISO_C_VISIBLE 1999 #elif _POSIX_C_SOURCE >=3D 199506 #define __POSIX_VISIBLE 199506 #define __ISO_C_VISIBLE 1990 #elif _POSIX_C_SOURCE >=3D 199309 #define __POSIX_VISIBLE 199309 #define __ISO_C_VISIBLE 1990 #elif _POSIX_C_SOURCE >=3D 199209 #define __POSIX_VISIBLE 199209 #define __ISO_C_VISIBLE 1990 #elif _POSIX_C_SOURCE >=3D 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. Th= is * makes no difference to the preprocessor (undefined symbols in prepro= cessing * expressions are defined to have value zero), but makes it more conve= nient for * a test program to print out the values. * * If a program mistakenly defines _ANSI_SOURCE and some other macro su= ch as * _POSIX_C_SOURCE, we will assume that it wants the broader compilatio= n * 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 ca= n either remove problematic XOPEN macros from mk/meson rules (drivers/net/fai= lsafe, 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 mak= es 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.