Re: [PATCH] perf build: Support passing extra Clang options via EXTRA_BPF_FLAGS

[hupu]

Hi Leo,
On Thu, Dec 11, 2025 at 6:40 PM Leo Yan <leo.yan@xxxxxxx> wrote:
>
> On Wed, Nov 26, 2025 at 09:44:02PM +0800, hupu wrote:
>
> Please don't spam on mailing list as you did. It is really bad practice.
> You could find resources [1][2] to learn upstreaming and co-work on the
> ML.
>

I apologize for the inconvenience caused by my frequent emails. I only
hoped to bring this nearly two-month-long discussion to a conclusion
sooner.


> > The eBPF skeleton is compiled via clang --target=bpf, and its header
> > file search paths mainly come from BPF_INCLUDE and TOOLS_UAPI_INCLUDE.
> > It also uses '-idirafter' to include the host’s /usr/local/include and
> > /usr/include directories in the search path. This process is not
> > directly coupled with cross-compilation managed via pkg-config, which
> > means PKG_CONFIG_SYSROOT_DIR does not affect how the skeleton resolves
> > its headers.
>
> Based on my limited knowledge, Clang does not provide its own headers.
> It needs to rely on GCC's headers for compilation.  I do see the
> Makefile does right thing for finding headers:
>
>   Makefile.perf:1203: ***
>   CLANG_SYS_INCLUDES=-idirafter /usr/lib/llvm-18/lib/clang/18/include
>   -idirafter /usr/local/include
>   -idirafter /usr/bin/../lib/gcc-cross/aarch64-linux-gnu/14/../../../../aarch64-linux-gnu/include
>   -idirafter /usr/include/aarch64-linux-gnu
>   -idirafter /usr/include
>
> It is mess to add some random include paths and feed to clang.  We
> already have provided a reliable way for building eBPF skelton program
> - keep in mind, eBPF skeleton program is not any aarch64 cross
> compilation, we just use clang for building bpf target.
>
> My understanding is you don't have a sane setting up on your local
> building env.
>

Although I have explained my view in earlier emails, it seems the
discussion has returned to the initial state.

Indeed, as you mentioned in the early discussion, running the
following commands on the host to install certain packages can
successfully compile perf:
> $ sudo apt-get install gcc-aarch64-linux-gnu g++-aarch64-linux-gnu
> $ sudo apt-get install libc6-dev-aarch64-cross linux-libc-dev-aarch64-cross
> $ sudo apt-get install libc6-dev-arm64-cross linux-libc-dev-arm64-cross


However, I don’t think relying on the host build environment is the
best approach, for several reasons:

a) These commands install UAPI header files on the host, especially
`linux-libc-dev-aarch64-cross` and `linux-libc-dev-arm64-cross`. These
headers originate from the kernel source tree’s `include/uapi/` and
`arch/arm64/include/uapi/` directories, and their versions are tied to
the *HOST* kernel version. If the target kernel version is different,
mismatches may cause compilation errors or even runtime failures.

b) Even if `perf` can be compiled and run successfully now, there is
no guarantee that the kernel source headers will always match the
host-installed UAPI headers as the upstream kernel evolves.

c) In scenarios where the host acts as a general build server and
needs to build multiple target kernel versions, it is not possible to
ensure that the host UAPI headers are compatible with all target
versions.

d) As you pointed out, `CLANG_SYS_INCLUDES` does include host headers,
but it uses `-idirafter` instead of `-I`. This means the host headers
have lower priority. This change was introduced in commit a2af0f6b8ef7
("perf build: Add system include paths to BPF builds"); as noted in
the commit message, the preferred approach is to use kernel source
headers rather than potentially older ones from the system.


Based on this, I propose the following include order:
- Prefer kernel source headers
  [RFC] perf build: Use self-contained headers from kernel source when compiling
  https://lore.kernel.org/all/20251124072310.3592-1-hupu.gm@xxxxxxxxx/

- Allow users to specify header search paths matching the target
kernel version (eg. via `EXTRA_BPF_FLAGS`)
  [PATCH] perf build: Support passing extra Clang options via EXTRA_BPF_FLAGS
  https://lore.kernel.org/all/20251013080609.2070555-1-hupu.gm@xxxxxxxxx/

- Fall back to the host build environment only if necessary


In summary, while relying on the host build environment can fix the
current build issue, I believe it is not the optimal solution.

Anyway, regardless of the final decision, I will respect it. Before
concluding, I hope we can explore this further and involve more
maintainers in the discussion. As for your comment, "you don't have a
sane setting up on your local building env", I am not yet fully
convinced by this reason.

Lastly, I once again apologize for any disturbance caused by my
frequent emails, and I sincerely thank both you and Namhyung for your
involvement throughout this process. I also hope this discussion will
attract more attention so that additional maintainers can participate.

Thanks,
hupu