Hi Ross, On Fri, Dec 04, 2015 at 09:11:59AM +0000, Burton, Ross wrote: >Hi Maxin, > >>On 2 December 2015 at 07:56, Maxin B. John <maxin.j...@intel.com> wrote: >> >> Moving libjpeg-turbo from meta-oe as a replacement for libjpeg >> package. libjpeg-turbo has same API/ABI as libjpeg. It is >> relatively faster in JPEG compression/decompression than libjpeg. >> > > As jpeg-turbo has assembler bits it's getting all confused about x32: > > | checking if we have SIMD optimisations for cpu type... yes > (x86_64) > | checking for nasm... nasm > | checking for object file format of host system... ELF64 > | checking for object file format specifier (NAFLAGS) ... -felf64 > -DELF -D__x86_64__ > | checking whether the assembler (nasm -felf64 -DELF -D__x86_64__) > works... yes > | checking whether the linker accepts assembler output... no > | configure: error: configuration problem: maybe object file > format mismatch. > > > (https://autobuilder.yoctoproject.org/main/builders/nightly-x32/builds/545)
There was a discussion about supporting x32 support in libjpeg-turbo: http://sourceforge.net/p/libjpeg-turbo/patches/35/ Due to some reasons, that ended up in "closed-wont-integrate". Work-around could be to build with "--without-simd" for x32 or implement the x32 assembly SIMD routines to support that feature (long and painful). >Ross Best Regards, Maxin -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
