The arm64 build failed at: gcc -o commandfilter.so commandfilter.xo -shared -pie -Wl,-z,relro -Wl,-z,now /usr/bin/ld: Scrt1.o: in function `_start': undefined reference to `main' Redis does not link executables only, which is what this recipe assumed. Its test modules are shared objects, tests/modules/Makefile links them with `$(SHOBJ_LDFLAGS) $(LDFLAGS)`, and Redis 8.x builds them as part of the default target — so -pie in LDFLAGS becomes `gcc -shared -pie` and the linker goes looking for main in a shared object. src/Makefile composes FINAL_LDFLAGS = $(LDFLAGS) $(OPT) $(REDIS_LDFLAGS) and reaches it only through REDIS_LD, which links redis-server, redis-cli and redis-benchmark — exactly the three binaries the recipe verifies. The modules Makefile never mentions REDIS_LDFLAGS. So -pie moves there and LDFLAGS keeps the hardening flags, which are valid for shared objects too. That puts redis on the same footing as the recipes that already split the two: CPython's LINKFORSHARED, PHP's EXTRA_LDFLAGS_PROGRAM, Postgres's LDFLAGS_EX. Fixes the same latent bug in dragonfly, found while auditing the rest: it had -pie in LDFLAGS *and* passed -DCMAKE_EXE_LINKER_FLAGS. CMake seeds CMAKE_SHARED_LINKER_FLAGS from LDFLAGS as well, so the LDFLAGS copy was both redundant and a trap waiting for the first shared object the build produces. After the audit only node and bun still carry -pie in LDFLAGS. A default node build genuinely links no shared objects; bun is unverified and already the most fragile recipe here. Both rest on the assumption that just proved wrong for redis, and only a real build will settle them.