meson options - build vs target machine cpuflags question

[Dan Gora]

On Thu, Mar 10, 2022 at 11:46 AM Sanford, Robert <rsanford at akamai.com> wrote:
>
> Hello All,
>
> We build a DPDK 21.05 app on Intel x86 machines with RDSEED in cpuflags, and may run it on machines *without* RDSEED.
> This results in a fatal error ...
> ERROR: This system does not support "RDSEED".
> Please check that RTE_MACHINE is set correctly.
> EAL: FATAL: unsupported cpu type.
>
> I try adding -Dplatform=haswell when running meson, (because gcc man page indicates that haswell is last arch w/o RDSEED) but get the same result.
> Until we resolve it, our workaround is changing the error-out in rte_cpu_is_supported() to just print a warning and continue.
> We don't have direct access to automated build machines, we go through change request processes, and so we can't rapidly try too many things.
>
> Is there a better meson option, such as machine=haswell, or something else that will work?
>
> Thanks in advance,
> Robert Sanford

I tried four times to get a simple fix for this (and the lack of
getentropy() on older glibc) to determine the entropy source at run
time and got nothing but an endless raft of shit and ridiculous
criticisms that I completely gave up trying to contribute to DPDK ever
again.

The DPDK developers think that it's your responsibility to have a
separate build system for each of your target systems and platforms
and that if you don't you're basically a big dummy.

Don't believe me?  Go look through the archives:

"[PATCH 2/2] eal: resolve getentropy at run time for random seed"
"[PATCH v4 2/2] eal: emulate glibc getentropy for initial random seed".

I suggest that you just fork DPDK and use one of those patches and
just maintain a separate DPDK tree.  That's what I did.  It's way
easier than trying to get anything upstream.

thanks
dan