Re: [PATCH v8] kbuild: host: use single executable for rustc -C linker

On Sat, May 9, 2026 at 12:20 PM Mohamad Alsadhan <[email protected]> wrote:
>
> rustc's -C linker= option expects a single executable path. When
> HOSTCC contains a wrapper (e.g. "ccache gcc"), passing
> `-Clinker=$(HOSTCC)` results in the shell splitting the value into
> multiple words, and rustc interprets the additional word as an
> input filename:

I have been taking a look at this, and considered applying it since
Kbuild is OK with it (thanks a lot for all the work during the
different versions), but I am not sure if the following bits are all
intended:

  - Shouldn't `HOSTRUSTC_LD` be documented in `Documentation/kbuild/kbuild.rst`?

  - Why do we do both `clean-files` and `CLEAN_FILES`?

    + In fact, should we do it on `clean` or `mrproper`? Nicolas
originally suggested `MRPROPER_FILES`, but this is on `CLEAN_FILES`.
But more on that below, since I guess it depends on how we treat
out-of-tree modules...

  - Was this tested with an out-of-tree module? I am asking because:

    + It does create an unused wrapper in a `scripts/` folder in the
out-of-tree module directory (i.e. the one used is the in-tree one) --
is that intended?

    + If we remove the wrapper during `clean` as the patch currently
does, then it means we cannot build Rust host programs in an
out-of-tree module (because it uses the in-tree one). Should it be in
`mrproper` instead, or should we generate a per-out-of-tree-module
one?

      While I think the kernel generally expects that the same
toolchain is used for both the main build and out-of-tree modules (it
may happen to work otherwise, but as a policy it is not supposed to be
supported, or at least that is what I recall I was told), I am not
sure if it applies to host programs. I guess someone may want to use a
different host toolchain vs. the one used to build the main kernel,
and I guess things would generally work.

  - The `filechk` could fail if we use Rust host programs in more
folders later on, i.e. if two submakes run it at the same time, and
one at the end deletes the (shared) temporary, then the other will
fail if it was in the middle of updating it.

  - Since we have now `zerocopy-derive`, which is a proc macro, I had
to add a dependency for that one too like the other two.

Some good news, though, is that the whole `clean` thing made me
realize I missed the `mrproper` for `zerocopy-derive`, so I am sending
a quick patch for that.

Cheers,
Miguel