From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <stable-bounces@dpdk.org> Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 1BE5EA034F for <public@inbox.dpdk.org>; Fri, 26 Feb 2021 10:47:09 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id DE40640692; Fri, 26 Feb 2021 10:47:08 +0100 (CET) Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by mails.dpdk.org (Postfix) with ESMTP id E6EEE40692; Fri, 26 Feb 2021 10:47:04 +0100 (CET) IronPort-SDR: k/+RHjWkr+6EwI357bmTTDKG+sj3dDkEbg5c+aC5scQGH/zyLOsns23Vz8/kW88zdlw2PRdPyE qElNgBy/81sA== X-IronPort-AV: E=McAfee;i="6000,8403,9906"; a="185882414" X-IronPort-AV: E=Sophos;i="5.81,208,1610438400"; d="scan'208";a="185882414" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Feb 2021 01:47:03 -0800 IronPort-SDR: 0cfNWn8UlqCFq/1MNfxLF3kMWTPZn+g9PjhIXhxDifWbhmd5qWg4PFvIq3YEes3wgzTNGbmxSI P7YrPCQ5Vfaw== X-IronPort-AV: E=Sophos;i="5.81,208,1610438400"; d="scan'208";a="404831952" Received: from bricha3-mobl.ger.corp.intel.com ([10.252.16.207]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA; 26 Feb 2021 01:46:59 -0800 Date: Fri, 26 Feb 2021 09:46:56 +0000 From: Bruce Richardson <bruce.richardson@intel.com> To: Thomas Monjalon <thomas@monjalon.net> Cc: dev@dpdk.org, ncopa@alpinelinux.org, stable@dpdk.org, Hemant Agrawal <hemant.agrawal@nxp.com>, Sachin Saxena <sachin.saxena@oss.nxp.com>, Jakub Grajciar <jgrajcia@cisco.com>, Matan Azrad <matan@nvidia.com>, Shahaf Shuler <shahafs@nvidia.com>, Viacheslav Ovsiienko <viacheslavo@nvidia.com>, Cristian Dumitrescu <cristian.dumitrescu@intel.com>, John McNamara <john.mcnamara@intel.com>, Maxime Coquelin <maxime.coquelin@redhat.com>, Chenbo Xia <chenbo.xia@intel.com>, Anatoly Burakov <anatoly.burakov@intel.com>, Konstantin Ananyev <konstantin.ananyev@intel.com>, Marcin Smoczynski <marcinx.smoczynski@intel.com> Message-ID: <20210226094656.GD1308@bricha3-MOBL.ger.corp.intel.com> References: <20190313170657.16688-1-ncopa@alpinelinux.org> <20210225182250.1149592-5-thomas@monjalon.net> <20210226090803.GA1308@bricha3-MOBL.ger.corp.intel.com> <2843306.ICY3tYd9bS@thomas> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2843306.ICY3tYd9bS@thomas> Subject: Re: [dpdk-stable] [PATCH v5 04/17] build: define _GNU_SOURCE globally X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: patches for DPDK stable branches <stable.dpdk.org> List-Unsubscribe: <https://mails.dpdk.org/options/stable>, <mailto:stable-request@dpdk.org?subject=unsubscribe> List-Archive: <http://mails.dpdk.org/archives/stable/> List-Post: <mailto:stable@dpdk.org> List-Help: <mailto:stable-request@dpdk.org?subject=help> List-Subscribe: <https://mails.dpdk.org/listinfo/stable>, <mailto:stable-request@dpdk.org?subject=subscribe> Errors-To: stable-bounces@dpdk.org Sender: "stable" <stable-bounces@dpdk.org> On Fri, Feb 26, 2021 at 10:40:32AM +0100, Thomas Monjalon wrote: > 26/02/2021 10:08, Bruce Richardson: > > On Thu, Feb 25, 2021 at 07:22:37PM +0100, Thomas Monjalon wrote: > > > There was an intent to define _GNU_SOURCE globally, > > > but it was not set in pkg-config for external applications. > > > > > Is this something that we really want to do, to force all external apps to > > use _GNU_SOURCE when compiling? Do some of our header files rely on > > definitions only available with _GNU_SOURCE? If so, we should probably look > > to remove that dependency rather than mandating the define. > > From patch 5: > In musl libc, cpu_set_t is defined only if _GNU_SOURCE is defined. > > If we avoid mandating _GNU_SOURCE, > we must #ifdef functions relying on rte_cpuset_t in the headers: > - rte_lcore_cpuset > - rte_thread_set_affinity > - rte_thread_get_affinity > - rte_telemetry_init (internal) > Or a different trick in linux/include/rte_os.h could be: > typedef void rte_cpuset_t; > so it allows including files, but not using above functions of course. > Can we just define _GNU_SOURCE in the header file with rte_cpuset_t?