mirror of
https://github.com/openembedded/meta-openembedded.git
synced 2026-08-31 15:51:17 +00:00
Khem Raj
5f6c8eb030
thirdparty/zstd.cmake compiles the bundled zstd's huf_decompress.c but not the assembly file it pairs with, zstd/lib/decompress/huf_decompress_amd64.S. zstd selects the assembly fast loops in portability_macros.h whenever !defined(ZSTD_DISABLE_ASM) && ZSTD_ASM_SUPPORTED && defined(__x86_64__) && (DYNAMIC_BMI2 || defined(__BMI2__)) so the DYNAMIC_BMI2=0 that apitrace already sets is not enough: any x86-64 tune whose -march implies BMI2, such as x86-64-v3, still takes that path and fails to link: | ld.lld: error: undefined hidden symbol: HUF_decompress4X2_usingDTable_internal_fast_asm_loop | >>> referenced by huf_decompress.c:1739 | >>> thirdparty/apitrace.lto.libzstd_bundled.a(huf_decompress.c.o) | ld.lld: error: undefined hidden symbol: HUF_decompress4X1_usingDTable_internal_fast_asm_loop | >>> referenced by huf_decompress.c:917 Plain -march=x86-64 does not define __BMI2__, which is why only the more specific tunes are affected. Define ZSTD_DISABLE_ASM so the C fast loops are used consistently, which is already what every non-BMI2 build gets. Not fixed upstream: master carries the same zstd.cmake, no commit since tag 14.0 touches it, and none of the 19 open pull requests or any issue covers this. Verified on x86-64 for qemux86-64 (x86-64-v3 tune): do_compile fails before the change while linking gltrim and apitrace, and do_compile, do_install and do_package succeed after. Signed-off-by: Khem Raj <khem.raj@oss.qualcomm.com>