[v5,04/17] build: define _GNU_SOURCE globally
Checks
Commit Message
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(-)
Comments
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.
@@ -398,8 +398,6 @@ if cc.has_argument('-Wno-format-truncation')
cflags += '-Wno-format-truncation'
endif
-# specify -D_GNU_SOURCE unconditionally
-cflags += '-D_GNU_SOURCE'
# Strict-aliasing rules are violated by uint8_t[] to context size casts.
cflags += '-fno-strict-aliasing'
@@ -3,6 +3,7 @@
pkg = import('pkgconfig')
pkg_extra_cflags = ['-include', 'rte_config.h'] + machine_args
+pkg_extra_cflags += '-D_GNU_SOURCE'
if is_freebsd
pkg_extra_cflags += ['-D__BSD_VISIBLE']
endif
@@ -8,9 +8,6 @@
#ifndef HEADER_COMPAT_H
#define HEADER_COMPAT_H
-#ifndef _GNU_SOURCE
-#define _GNU_SOURCE
-#endif
#include <stdio.h>
#include <stdint.h>
#include <stdlib.h>
@@ -10,10 +10,6 @@
#define __COMPAT_H
#include <sched.h>
-
-#ifndef _GNU_SOURCE
-#define _GNU_SOURCE
-#endif
#include <stdint.h>
#include <stdlib.h>
#include <stddef.h>
@@ -10,7 +10,6 @@ sources = files('dpaax_iova_table.c', 'dpaa_of.c', 'caamflib.c')
includes += include_directories('caamflib')
-cflags += ['-D_GNU_SOURCE']
if cc.has_argument('-Wno-cast-qual')
cflags += '-Wno-cast-qual'
endif
@@ -5,10 +5,6 @@
#ifndef _RTE_ETH_MEMIF_H_
#define _RTE_ETH_MEMIF_H_
-#ifndef _GNU_SOURCE
-#define _GNU_SOURCE
-#endif /* GNU_SOURCE */
-
#include <sys/queue.h>
#include <ethdev_driver.h>
@@ -2,10 +2,6 @@
* Copyright 2019 Mellanox Technologies, Ltd
*/
-#ifndef _GNU_SOURCE
-#define _GNU_SOURCE
-#endif
-
#include <sys/types.h>
#include <sys/socket.h>
#include <sys/un.h>
@@ -47,7 +47,7 @@ $(error "Cannot generate statically-linked binaries with this version of pkg-con
endif
endif
-CFLAGS += -I. -DALLOW_EXPERIMENTAL_API -D_GNU_SOURCE
+CFLAGS += -I. -DALLOW_EXPERIMENTAL_API
OBJS := $(patsubst %.c,build/%.o,$(SRCS-y))
@@ -2,10 +2,6 @@
* Copyright(c) 2010-2016 Intel Corporation
*/
-#ifndef _GNU_SOURCE
-#define _GNU_SOURCE
-#endif
-
#include <stdio.h>
#include <stdlib.h>
#include <stdint.h>
@@ -18,7 +18,6 @@ endif
endif
CFLAGS += -DALLOW_EXPERIMENTAL_API
-CFLAGS += -D_GNU_SOURCE
LDFLAGS += "-Wl,--copy-dt-needed-entries"
# Build using pkg-config variables if possible
@@ -38,7 +38,7 @@ $(error "Cannot generate statically-linked binaries with this version of pkg-con
endif
endif
-CFLAGS += -I. -DALLOW_EXPERIMENTAL_API -D_GNU_SOURCE
+CFLAGS += -I. -DALLOW_EXPERIMENTAL_API
OBJS := $(patsubst %.c,build/%.o,$(SRCS-y))
@@ -2,12 +2,8 @@
* Copyright(c) 2010-2019 Intel Corporation
*/
-#ifndef _GNU_SOURCE
-#define _GNU_SOURCE
-#endif
#include <pthread.h>
#include <sched.h>
-
#include <stdint.h>
#include <unistd.h>
#include <stdbool.h>