@@ -43,6 +43,15 @@ EXTRA_OEMAKE += "${PACKAGECONFIG_CONFARGS}"
TARGET_LDFLAGS:append = " ${DEBUG_PREFIX_MAP}"
+# The bundled xxHash marks its XXH3 vector paths always_inline but only reaches
+# them through function pointers. It drops the inline hints on its own when
+# __NO_INLINE__ is defined (-O0, -fno-inline) but never for -Og, and recent GCC
+# no longer resolves those indirect calls at -Og, so deps/xxhash fails to
+# build. Upstream xxHash closed this as not fixable in code and documents
+# XXH_NO_INLINE_HINTS as the supported way to compile with -Og. This is the
+# same workaround oe-core applies to the standalone xxhash recipe.
+CFLAGS += "${@bb.utils.contains('SELECTED_OPTIMIZATION', '-Og', '-DXXH_NO_INLINE_HINTS', '', d)}"
+
do_compile:prepend() {
oe_runmake -C deps hdr_histogram fpconv hiredis lua linenoise
}
redis 8.4 started bundling an xxHash snapshot in deps/xxhash, which is built and linked into redis-server. The snapshot reports itself as 0.8.3 but does not match that release: it carries RISC-V Vector and LoongArch LASX backends that landed after the v0.8.3 tag, so the system xxhash is not a substitute for it. Its XXH3 accumulate and scramble routines are marked always_inline but are only ever reached through function pointers, so the compiler has to resolve the indirect call before it can honour the attribute. xxHash drops those inline hints on its own when __NO_INLINE__ is defined, which covers -O0 and -fno-inline, but nothing covers -Og. Recent GCC no longer resolves the indirect calls at that optimisation level, so every build with DEBUG_BUILD = "1" fails: xxhash.h:5476:1: error: inlining failed in call to 'always_inline' 'XXH3_scrambleAcc_neon': function not considered for inlining make[2]: *** [Makefile:108: xxhash] Error 2 ld: cannot find ../deps/xxhash/libxxhash.a: No such file or directory Upstream xxHash closed this as not fixable in code (Cyan4973/xxHash#943) and instead documents XXH_NO_INLINE_HINTS as the supported way to compile with -Og. Define it when -Og is the selected optimisation, leaving regular builds untouched so xxHash keeps its inline hints there. oe-core already carries exactly this workaround for the standalone xxhash recipe, added in 3464c67cd3 ("xxhash: fix build with gcc 12") for the same -Og inlining failure, so use the identical expression here rather than a second spelling of the same condition. The bundled copy needs its own because redis builds deps/xxhash from its own tree and never links the system library. AI-Generated: Uses Claude Code Signed-off-by: Ricardo Salveti <ricardo.salveti@oss.qualcomm.com> --- v2: align the fix with oe-core's standalone xxhash recipe, which already carries this workaround: use the same bb.utils.contains(SELECTED_OPTIMIZATION, '-Og', ...) expression with CFLAGS += rather than an inline python conditional on CFLAGS:append, and reference 3464c67cd3 where oe-core added it. Also correct the first release that vendored xxHash (8.4, not 8.8) and state why the system xxhash cannot be used instead. No functional change. meta-oe/recipes-extended/redis/redis_8.10.0.bb | 9 +++++++++ 1 file changed, 9 insertions(+)