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.
