[v5,04/17] build: define _GNU_SOURCE globally

  There was an intent to define _GNU_SOURCE globally,
but it was not set in pkg-config for external applications.

The internal definition in config/meson.build is kept,
and one is added in buildtools/pkg-config/meson.build for external apps.
All other specific definitions of _GNU_SOURCE are removed.

Fixes: 5d7b673d5fd6 ("mk: build with _GNU_SOURCE defined by default")
Fixes: 28188cee2aa0 ("build: enable BSD features visibility for FreeBSD")
Cc: stable@dpdk.org

Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
---
 app/test/meson.build                              | 2 --
 buildtools/pkg-config/meson.build                 | 1 +
 drivers/bus/fslmc/qbman/include/compat.h          | 3 ---
 drivers/common/dpaax/compat.h                     | 4 ----
 drivers/common/dpaax/meson.build                  | 1 -
 drivers/net/memif/rte_eth_memif.h                 | 4 ----
 drivers/net/mlx5/linux/mlx5_socket.c              | 4 ----
 examples/ip_pipeline/Makefile                     | 2 +-
 examples/performance-thread/l3fwd-thread/main.c   | 4 ----
 examples/performance-thread/pthread_shim/Makefile | 1 -
 examples/pipeline/Makefile                        | 2 +-
 examples/vhost_blk/vhost_blk.c                    | 4 ----
 12 files changed, 3 insertions(+), 29 deletions(-)
  

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.
  

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.
  

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?
  

26/02/2021 10:46, Bruce Richardson:
> 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?

That would be the simplest solution yes :)
I don't really like defining such flag in a header file because
it impacts all code coming after the include.
It would mean all includes done after DPDK ones behave differently.

I vote for the trick:
#ifdef _GNU_SOURCE
	typedef cpu_set_t rte_cpuset_t;
#else
	typedef void rte_cpuset_t;
#endif

Opinions?
  

26/02/2021 11:04, Thomas Monjalon:
> 26/02/2021 10:46, Bruce Richardson:
> > 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?
> 
> That would be the simplest solution yes :)
> I don't really like defining such flag in a header file because
> it impacts all code coming after the include.
> It would mean all includes done after DPDK ones behave differently.
> 
> I vote for the trick:
> #ifdef _GNU_SOURCE
> 	typedef cpu_set_t rte_cpuset_t;
> #else
> 	typedef void rte_cpuset_t;
> #endif
> 
> Opinions?

I changed my mind, I think it is saner to not export functions
which use rte_cpuset_t, if the type is not defined.
The type definition is detected thanks to CPU_SETSIZE
and a new definition is used inside DPDK: RTE_HAS_CPUSET.
I think it is more elegant and easier to debug.
I am sending a v6.