From: Josh Poimboeuf <[email protected]> Sent: Tuesday, November 11, 2025 12:09 PM > > On Wed, Nov 05, 2025 at 03:22:58PM +0000, Michael Kelley wrote: > > > Thanks for reporting that. I suppose something like the below would work? > > > > > > Though, maybe the missing xxhash shouldn't fail the build at all. It's > > > really only needed for people who are actually trying to run klp-build. > > > I may look at improving that. > > > > Yes, that would probably be better. > > > > > > > > diff --git a/tools/objtool/Makefile b/tools/objtool/Makefile > > > index 48928c9bebef1..8b95166b31602 100644 > > > --- a/tools/objtool/Makefile > > > +++ b/tools/objtool/Makefile > > > @@ -12,7 +12,7 @@ ifeq ($(SRCARCH),loongarch) > > > endif > > > > > > ifeq ($(ARCH_HAS_KLP),y) > > > - HAVE_XXHASH = $(shell echo "int main() {}" | \ > > > + HAVE_XXHASH = $(shell echo -e "#include <xxhash.h>\nXXH3_state_t > > > *state;int main() {}" | \ > > > $(HOSTCC) -xc - -o /dev/null -lxxhash 2> /dev/null && > > > echo y || echo n) > > > ifeq ($(HAVE_XXHASH),y) > > > BUILD_KLP := y > > > > Indeed this is what I had in mind for the enhanced check. But the above > > gets a syntax error: > > > > Makefile:15: *** unterminated call to function 'shell': missing ')'. Stop. > > make[4]: *** [Makefile:73: objtool] Error 2 > > > > As a debugging experiment, adding only the -e option to the existing code > > like this shouldn't affect anything, > > > > HAVE_XXHASH = $(shell echo -e "int main() {}" | \ > > > > but it causes HAVE_XXHASH to always be 'n' even if the xxhash library > > is present. So the -e option is somehow fouling things up. > > > > Running the equivalent interactively at a 'bash' prompt works as expected. > > And your proposed patch works correctly in an interactive bash. So > > something weird is happening in the context of make's shell function, > > and I haven't been able to figure out what it is. > > > > Do you get the same failures? Or is this some kind of problem with > > my environment? I've got GNU make version 4.2.1. > > That's weird, it builds fine for me. I have GNU make 4.4.1.
I've been able to debug this. Two problems: 1) On Ubuntu (both 20.04 and 24.04), /bin/sh and /usr/bin/sh are symlinks to "dash" (not "bash"). So the "shell" command in "make" invokes dash. The man page for dash shows that the built-in echo command accepts only -n as an option. The -e behavior of processing "\n" and similar sequences is always enabled. So on my Ubuntu systems, the "-e" is ignored by echo and becomes part of the C source code sent to gcc, and of course it barfs. Dropping the -e makes it work for me (and the \n is handled correctly), but that might not work with other shells. Using "/bin/echo" with the -e solves the problem in a more compatible way across different shells. 2) With make v4.2.1 on my Ubuntu 20.04 system, the "#" character in the "#include" added to the echo command is problematic. "make" seems to be treating it as a comment character, though I'm not 100% sure of that interpretation. Regardless, the "#" causes a syntax error in the "make" shell command. Adding a backslash before the "#" solves that problem. On an Ubuntu 24.04 system with make v4.3, the "#" does not cause any problems. (I tried to put make 4.3 on my Ubuntu 20.04 system, but ran into library compatibility problems so I wasn’t able to definitively confirm that it is the make version that changes the handling of the "#"). Unfortunately, adding the backslash before the # does *not* work with make v4.3. The backslash becomes part of the C source code sent to gcc, which barfs. I don't immediately have a suggestion on how to resolve this in a way that is compatible across make versions. What a mess. Michael
