[oe] [meta-oe][PATCH v2] abseil-cpp: add recipe for git version

Khem Raj raj.khem at gmail.com
Mon Feb 10 19:36:50 UTC 2020


On Mon, Feb 10, 2020 at 11:31 AM Sinan Kaya <okaya at kernel.org> wrote:
>
> On 2/10/2020 1:17 PM, Andrey Zhizhikin wrote:
> >> +TARGET_CXXFLAGS += "${@bb.utils.contains('TARGET_ARCH', 'aarch64', '
> >> -march=armv8-a+crypto', '', d)}"
> > This cannot be enforced, as it would break those AArch64 derivatives,
> > which does not have Crypto extension. See my comment above, where I
> > extracted 2 sets of tune features for Cortex-A53. That means that
> > there are SoCs there from different vendors, and some vendors decided
> > to license Crypto extensions from ARM to include it in their RTL, but
> > some opted out to save either space on a die or cost of the processor.
> >
> > If you would base your build with '+crypto' unconditionally, then the
> > binary would segfault on those SoCs which has Crypto opted out.
> >
> > Moreover, enabling crypto extension in GCC automatically enables
> > inlined NEON and VFP opcodes (see [1]), and there are more side
> > effects to be expected on those SOCs which does not have those
> > integrated.
> >
>
> I agree. I dropped this line on v3.
>
> I was curious about
>
> TARGET_CXXFLAGS += "${@bb.utils.contains('TARGET_ARCH', 'x64', ' -maes
> -msse4.1', '', d)}"
>
> do we have a feature flag for this too?
>

perhaps look for corei7 in TUNE_FEATURES

> Code doesn't compile without arch crypt support.
> --
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel at lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-devel


More information about the Openembedded-devel mailing list