26/02/2021 10:46, Bruce Richardson:

On Fri, Feb 26, 2021 at 10:40:32AM +0100, Thomas Monjalon wrote:

quoted

26/02/2021 10:08, Bruce Richardson:

quoted

On Thu, Feb 25, 2021 at 07:22:37PM +0100, Thomas Monjalon wrote:

quoted

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?