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

[Khem Raj]

also fails on x86/musl

http://errors.yoctoproject.org/Errors/Details/390565/

On Mon, Feb 10, 2020 at 11:36 AM Khem Raj <raj.khem at gmail.com> wrote:
>
> 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