From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.lore.kernel.org (Postfix) with ESMTP id E0884D37E51 for ; Wed, 14 Jan 2026 15:41:35 +0000 (UTC) Subject: Re: [PATCH v2 08/15] kernel-yocto.bbclass: Disable ccache when rust-kernel is enabled To: openembedded-core@lists.openembedded.org From: alban.moizan@smile.fr X-Originating-Location: FR (176.157.204.145) X-Originating-Platform: Linux Firefox 146 User-Agent: GROUPS.IO Web Poster MIME-Version: 1.0 Date: Wed, 14 Jan 2026 07:41:30 -0800 References: <20251230141540.1974380-1-Harish.Sadineni@windriver.com> <20251230141540.1974380-9-Harish.Sadineni@windriver.com> In-Reply-To: <20251230141540.1974380-9-Harish.Sadineni@windriver.com> Message-ID: <659490.1768405290403118898@lists.openembedded.org> Content-Type: multipart/alternative; boundary="9QpbM5odQGoHi9lS3qG3" List-Id: X-Webhook-Received: from 45-33-107-173.ip.linodeusercontent.com [45.33.107.173] by aws-us-west-2-korg-lkml-1.web.codeaurora.org with HTTPS for ; Wed, 14 Jan 2026 15:41:35 -0000 X-Groupsio-URL: https://lists.openembedded.org/g/openembedded-core/message/229337 --9QpbM5odQGoHi9lS3qG3 Content-Type: text/plain; charset="utf-8"; markup=markdown Content-Transfer-Encoding: quoted-printable Excuse me for the double mail, I was not yet subscribing to the mailing lis= t, so my mail was hidden. -------------------------- Hi everyone, I've been investigating the issue when enabling `ccache` for kernel builds = that involve Rust. First of all, as documented in the `ccache` issue tracker [1], `ccache` is = not directly compatible with Rust. Therefore the current goal is to keep `ccache` enabled for the C portions o= f the kernel while bypassing it for Rust. While an alternative like `sccache` [2], compatible with both C and Rust ex= ists, you will see below that the underlying issue is the same, so just rep= lacing `ccache` by `sccache` will change nothing here. The issue (commit 235e6d49e5888ad04416219e10b6df91a738661a + this patch): When `ccache` is enabled, `${CC}` to `${CCACHE}{CC}`, ex: `gcc` to `ccache = gcc` Then, when compiling the kernel, `scripts/Makefile.host` will give it to `r= ustc` with `-Clinker=3D$(HOSTCC)` [3], but the shell expands `$(HOSTCC)` to= two words, therefore `rustc` takes `gcc` as another parameters, and it err= ors out.=20 I attempted to resolve it by modifying the incriminated Makefile in the fol= lowing ways: Trial 1: Quoting HOSTCC in Kernel Makefile Modify `scripts/Makefile.host` to wrap `HOSTCC` in quotes to ensure it is p= assed as a single string parameter: Replace `-Clinker=3D$(HOSTCC)` to `-Clinker=3D'$(HOSTCC)'` Result: Failure, `rustc` looks for a binary path literally named `ccache gc= c`, which does not exist, indeed, `-Clinker` argument value is treated by `= rustc` as a real path, and not a command [4]. Trial 2: Splitting HOSTCC into Linker and Pre-link Args Modified `scripts/Makefile.host` to force the linker to the first word of `= HOSTCC` and pass subsequent words to `-Zpre-link-args`: Replace `-Clinker=3D$(HOSTCC)` by `-Clinker=3D$(firstword $(HOSTCC)) -Zpre-= link-args=3D'$(wordlist 2,$(words $(HOSTCC)),$(HOSTCC))'` Result: Failure, `rustc` executes the command as: "ccache" "-m64" "gcc" ...= . This is invalid because in `rustc`, the target-specific pre-link arguments = (from `compiler/rustc_target/src/spec/targets/x86_64_unknown_linux_gnu.rs`)= are added before our custom args, placing `-m64` before the `gcc` executab= le [5] . Proposed Solutions 1. Kernel + Rust Patch (A): Patch the kernel Makefile (like the Trial 1) an= d patch `rustc` to accept a command string (with arguments) for `-Clinker` = instead of a strict Path. 2. Kernel + Rust Patch (B): Patch the kernel Makefile (like the Trial 2) an= d patch `rustc` to use `post_link_args` instead of `pre_link_args` for targ= et-specific values, ensuring the executable stays at the end of the command= . 3. Shell Wrappers: Implement shell wrappers for CC, CXX, etc. This would al= low `rustc` to call a single wrapper script, hiding `ccache` from it. 4. Kernel only: Patch the kernel Makefile to filter out `ccache` from CC (w= orks in practice but not generic for a possible other wrapper in the future= ). 5. Leave as-is: disable `ccache` when rust is enabled . Risks and Considerations - Upstreamability: Patching rust and the kernel at the same time could take= time.=20 - Maintainability: While the shell wrapper approach is more flexible and so= lves the issue for other tools with similar limitations, it might make debu= gging in Yocto more difficult and requires significant changes. I'm leaning towards the 1st or the 3rd approach, but I'd appreciate the mai= ntainers' thoughts on which path fits the OE architecture best. [1] https://github.com/ccache/ccache/issues/364 [2] https://github.com/mozilla/sccache [3] https://git.yoctoproject.org/linux-yocto/tree/scripts/Makefile.host?h= =3Dv6.18.1#n94 [4] https://github.com/rust-lang/rust/blob/4931e09e3ac3182d2a00f38cccfdf68e= 8e385e1c/compiler/rustc_codegen_ssa/src/back/link.rs#L1419 [5] https://github.com/rust-lang/rust/blob/4931e09e3ac3182d2a00f38cccfdf68e= 8e385e1c/compiler/rustc_codegen_ssa/src/back/link.rs#L1870 Best regards, Alban Moizan --9QpbM5odQGoHi9lS3qG3 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Excuse me for the double mail, I was not yet subscribing to the mailing = list, so my mail was hidden.

Hi everyone,

I've been investigating the issue when enabling ccache for = kernel builds that involve Rust.

First of all, as documented in the ccache issue tracker [1]= , ccache is not directly compatible with Rust. Therefore the current goal is to keep ccache enabled for the C= portions of the kernel while bypassing it for Rust. While an alternative like sccache [2], compatible with both C = and Rust exists, you will see below that the underlying issue is the same, = so just replacing ccache by sccache will change n= othing here.

The issue (commit 235e6d49e5888ad04416219e10b6df91a738661a + this patch)= :

When ccache is enabled, ${CC} to ${CCACH= E}{CC}, ex: gcc to ccache gcc

Then, when compiling the kernel, scripts/Makefile.host will= give it to rustc with -Clinker=3D$(HOSTCC) [3], = but the shell expands $(HOSTCC) to two words, therefore = rustc takes gcc as another parameters, and it errors ou= t.

I attempted to resolve it by modifying the incriminated Makefile in the = following ways:

Trial 1: Quoting HOSTCC in Kernel Makefile Modify scripts/Makefile.host to wrap HOSTCC in qu= otes to ensure it is passed as a single string parameter: Replace -Clinker=3D$(HOSTCC) to -Clinker=3D'$(HOSTCC)' Result: Failure, rustc looks for a binary path literally named= ccache gcc, which does not exist, indeed, -Clinker argument value is treated by rustc as a real path, and not = a command [4].

Trial 2: Splitting HOSTCC into Linker and Pre-link Args Modified scripts/Makefile.host to force the linker to the firs= t word of HOSTCC and pass subsequent words to -Zpre-link= -args: Replace -Clinker=3D$(HOSTCC) by -Clinker=3D$(firstword $= (HOSTCC)) -Zpre-link-args=3D'$(wordlist 2,$(words $(HOSTCC)),$(HOSTCC))' Result: Failure, rustc executes the command as: "ccache&q= uot; "-m64" "gcc" .... This is invalid because in rustc, the target-specific pre-link= arguments (from compiler/rustc_target/src/spec/targets/x86_64_unknow= n_linux_gnu.rs) are added before our custom args, placing -m64= before the gcc executable [5] .

Proposed Solutions 1. Kernel + Rust Patch (A): Patch the kernel Makefile (like the Trial 1) an= d patch rustc to accept a command string (with arguments) for = -Clinker instead of a strict Path. 2. Kernel + Rust Patch (B): Patch the kernel Makefile (like the Trial 2) an= d patch rustc to use post_link_args instead of pre_link_args for target-specific values, ensuring the executabl= e stays at the end of the command. 3. Shell Wrappers: Implement shell wrappers for CC, CXX, etc. This would al= low rustc to call a single wrapper script, hiding ccache= from it. 4. Kernel only: Patch the kernel Makefile to filter out ccache= from CC (works in practice but not generic for a possible other wrapper in= the future). 5. Leave as-is: disable ccache when rust is enabled .

Risks and Considerations - Upstreamability: Patching rust and the kernel at the same time could take= time. - Maintainability: While the shell wrapper approach is more flexible and so= lves the issue for other tools with similar limitations, it might make debu= gging in Yocto more difficult and requires significant changes.

I'm leaning towards the 1st or the 3rd approach, but I'd appreciate the = maintainers' thoughts on which path fits the OE architecture best.

[1] https://github.com/ccache/ccache/issues/364

[2] htt= ps://github.com/mozilla/sccache

[3] https://git.yoctoproject.org/= linux-yocto/tree/scripts/Makefile.host?h=3Dv6.18.1#n94

[4] https://github.com/rust-lang/rust/blob/4931e09e3ac3182d2a0= 0f38cccfdf68e8e385e1c/compiler/rustc_codegen_ssa/src/back/link.rs#L1419=

[5] https://github.com/rust-lang/rust/blob/4931e09e3ac3182d2a0= 0f38cccfdf68e8e385e1c/compiler/rustc_codegen_ssa/src/back/link.rs#L1870=

Best regards,

Alban Moizan

--9QpbM5odQGoHi9lS3qG3--