UAPI_HEADER_TEST and CC_CAN_LINK dependency

UAPI_HEADER_TEST and CC_CAN_LINK dependency

[Nick Desaulniers]

Hello Masahiro,

We'd like to be able to better test UAPI headers via
CONFIG_UAPI_HEAD_TEST=y with clang builds during cross compiling.
We're finding that CC_CAN_LINK=y is not enabled because clang (unlike
gcc) isn't configured with a cross libc in hand, and one may not be
available in the environment. This is a similar constraint to the
prebuilt GCC images distributed on kernel.org.

Looking at
commit d6fc9fcbaa65 ("kbuild: compile-test exported headers to ensure
they are self-contained")

Simply removing the dependency on CC_CAN_LINK=y allows us to run the
UAPI header tests, which pass on ARCH=arm64 and native x86_64 builds.
https://android-review.googlesource.com/c/kernel/common/+/1991156

I assume there may be some additional constraints perhaps for other
architectures or certain configs?

Another suggestion from the bionic maintainer to ensure the tests are
more hermetic/self-contained would be to add -ffreestanding to the
compiler invocations of these tests.

Do you have thoughts on how we might be able to eliminate the
dependency on CC_CAN_LINK for UAPI_HEADER_TEST? Otherwise, I suspect
we will have to use `USERCFLAGS=--sysroot=/path/to/sysroot` to make
CC_CAN_LINK work for clang cross compilation. See also:
commit f67695c9962e ("kbuild: Add environment variables for userprogs flags")

-- 
Thanks,
~Nick Desaulniers

Re: UAPI_HEADER_TEST and CC_CAN_LINK dependency

[Masahiro Yamada]

On Wed, Mar 2, 2022 at 4:49 AM Nick Desaulniers <ndesaulniers@google.com> wrote:
>
> Hello Masahiro,
>
> We'd like to be able to better test UAPI headers via
> CONFIG_UAPI_HEAD_TEST=y with clang builds during cross compiling.

I missed to add the target triple to usr/include/Makefile.
You might have thought you were cross-compiling the headers, but actually not.


Let me fix this first.
https://patchwork.kernel.org/project/linux-kbuild/patch/20220305125605.149913-1-masahiroy@kernel.org/




> We're finding that CC_CAN_LINK=y is not enabled because clang (unlike
> gcc) isn't configured with a cross libc in hand, and one may not be
> available in the environment. This is a similar constraint to the
> prebuilt GCC images distributed on kernel.org.
>
> Looking at
> commit d6fc9fcbaa65 ("kbuild: compile-test exported headers to ensure
> they are self-contained")
>
> Simply removing the dependency on CC_CAN_LINK=y allows us to run the
> UAPI header tests, which pass on ARCH=arm64 and native x86_64 builds.
> https://android-review.googlesource.com/c/kernel/common/+/1991156


Is it the right thing to cross-compile "#include <stdio.h>"
by using /usr/include/stdio.h ?


[with libc6-dev-arm64-cross package]

masahiro@grover:~/workspace$ clang --target=aarch64-linux-gnu  -c -o
test.o -Wp,-MD,\tmp.mk  test.c && grep stdio.h tmp.mk
  /usr/bin/../lib/gcc-cross/aarch64-linux-gnu/11/../../../../aarch64-linux-gnu/include/stdio.h
\

[without libc6-dev-arm64-cross package]

masahiro@grover:~/workspace$ clang --target=aarch64-linux-gnu  -c -o
test.o -Wp,-MD,\tmp.mk  test.c && grep stdio.h tmp.mk
test.o: test.c /usr/include/stdio.h /usr/include/bits/libc-header-start.h \


The header search path is like this:
 /usr/lib/llvm-13/lib/clang/13.0.0/include
 /usr/local/include
 /usr/bin/../lib/gcc-cross/aarch64-linux-gnu/11/../../../../aarch64-linux-gnu/include
 /usr/include


Even if the aarch64 libc is not installed,
you can cross-compile it because
clang finds stdio.h in /usr/include/.

Using the host's system headers for cross-compilation
looks wrong to me.



> I assume there may be some additional constraints perhaps for other
> architectures or certain configs?

No, I do not think so.
This is common for all architectures.


> Another suggestion from the bionic maintainer to ensure the tests are
> more hermetic/self-contained would be to add -ffreestanding to the
> compiler invocations of these tests.

I do not think so.

UAPI headers are part of hosted environments.
-ffreestanding does not make sense.



> Do you have thoughts on how we might be able to eliminate the
> dependency on CC_CAN_LINK for UAPI_HEADER_TEST? Otherwise, I suspect
> we will have to use `USERCFLAGS=--sysroot=/path/to/sysroot` to make
> CC_CAN_LINK work for clang cross compilation. See also:
> commit f67695c9962e ("kbuild: Add environment variables for userprogs flags")


If you want to use libc installed in a non-standard path,
yes, you can use --sysroot.

On debian or ubuntu for example, it is unneeded.
With "sudo apt install gcc-aarch64-linux-gnu", you can
enable CC_CAN_LINIK for clang without using --sysroot.


-- 
Best Regards
Masahiro Yamada