When you compile-test UAPI headers (CONFIG_UAPI_HEADER_TEST=y) with
Clang, they are currently compiled for the host target (likely x86_64)
regardless of the given ARCH=.
As a matter of fact, some exported headers include libc headers.
For example, include/uapi/sound/asound.h includes <stdlib.h> and <time.h>
after being exported. It is better to try to match the header search
paths to the target we are compiling them for.
Pick up the --target triple from KBUILD_CFLAGS in the same ways as
commit 7f58b487e9ff ("kbuild: make Clang build userprogs for target
architecture").
Signed-off-by: Masahiro Yamada <masahiroy@xxxxxxxxxx>
---
As far as I tested on Debian, Clang falls back to /usr/include/
when libc dev package for the specified target is not installed.
For example, --target=aarch64-linux-gnu tries to include
/usr/aarch64-linux-gnu/include/stdlib.h
, which is available when libc6-dev-arm64-cross is installed.
Otherwise, includes
/usr/include/stdlib.h
usr/include/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/usr/include/Makefile b/usr/include/Makefile
index 703ee034033e..19ac4b63866d 100644
--- a/usr/include/Makefile
+++ b/usr/include/Makefile
@@ -12,7 +12,7 @@ UAPI_CFLAGS += $(CLANG_FLAGS)
# In theory, we do not care -m32 or -m64 for header compile tests.
# It is here just because CONFIG_CC_CAN_LINK is tested with -m32 or -m64.
-UAPI_CFLAGS += $(filter -m32 -m64, $(KBUILD_CFLAGS))
+UAPI_CFLAGS += $(filter -m32 -m64 --target=%, $(KBUILD_CFLAGS))
# USERCFLAGS might contain sysroot location for CC.
UAPI_CFLAGS += $(USERCFLAGS)
--
2.32.0
