On Mon, Sep 16, 2019 at 3:34 PM Adrian Bunk <b...@stusta.de> wrote: > > On Mon, Sep 16, 2019 at 03:08:01PM -0700, Andre McCurdy wrote: > > On Mon, Sep 16, 2019 at 2:33 PM Christopher Larson <kerg...@gmail.com> > > wrote: > > > > > > This seems like something that could do with a ‘why’ in the commit > > > message and/or comments, to me. > > > > To be consistent with: > > > > > > https://git.openembedded.org/openembedded-core/commit/?id=1a563214caf6bd5b3a026ebe953f8c692ebd640a > >... > > libwebp sets -mfpu=neon when autodetecting, > is there a similar problem with ffmpeg? > > > > +# Do not trust configure to determine if ARM vfp or neon are available. > > > +# > > > +EXTRA_OECONF_ARM = " \ > > > + > > > ${@bb.utils.contains('TUNE_FEATURES','vfp','--enable-vfp','--disable-vfp', > > > d)} \ > > > + > > > ${@bb.utils.contains("TUNE_FEATURES",'neon','--enable-neon','--disable-neon',d)} > > > \ > >... > > If we cannot trust the vfp autodetection, why can we trust that the > autodetection of the vfp variant (vfpv2, vfpv3 or vfpv3-d16) and > the exact architecture (e.g. armv5te, armv6, armv6k or armv6t2) > are correct?
In general we can't. However these are all corner cases which are rarely (if ever) tested. For ffmpeg configuring with --enable-runtime-cpudetect (which I think we effectively do by default) probably hides a lot of the configure time misdetection too. > Which brings us back to the problem what the actual problem is (if any). I built for target without VFP or NEON and saw both as being enabled according to the configure log. Didn't investigate further than that. > cu > Adrian > > -- > > "Is there not promise of rain?" Ling Tan asked suddenly out > of the darkness. There had been need of rain for many days. > "Only a promise," Lao Er said. > Pearl S. Buck - Dragon Seed > -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core