Re: meson options - build vs target machine cpuflags question

[Dan Gora <dg@adax.com>]

On Thu, Mar 10, 2022 at 7:54 PM Dan Gora <dg@adax.com> wrote:
>
> On Thu, Mar 10, 2022 at 11:46 AM Sanford, Robert <rsanford@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".

Sorry, those are the getentropy() fixes.  This is the fix to determine
RDSEED at runtime:

"[PATCH 0/2] eal: choose initial PRNG seed source at runtime"

It was acked but I don't think that it was ever merged.