Re: [PATCH V9 1/4] rust: Fix "multiple candidates for rmeta dependency core" error

[Miguel Ojeda]

On Sat, Apr 4, 2026 at 2:16 PM Mukesh Kumar Chaurasiya (IBM)
<mkchauras@xxxxxxxxx> wrote:
>
> When building Rust code with LLVM=1 with -j1, rustc was encountering
> an error:
> "multiple candidates for `rmeta` dependency `core` found", with two
> candidates:
> 1. The host's standard library from the rustup toolchain
> 2. The kernel's custom libcore.rmeta in the rust/ directory

Please clarify in what conditions this happens, e.g. when building
natively in an architecture like powerpc for which the target (...)

Otherwise, it sounds like this is something that would be happening to
essentially everyone just by building with `-j1`, which is not the
case.

Also, since you may need to reword a bit, please take the chance to
use the present tense to describe the current state, and then the
imperative for what is changed. (The past is usually used for
something that already changed in the past, not for something that
still happens before the patch is applied -- I hope that makes sense).

> - Update rustdoc-pin_init to use explicit --extern paths for proc macros
>   as pin-init also needs alloc crate from -L$(objtree)/rust. So the proc
>   macros needs an absolute path

As Gary mentioned, this list may be too exhaustive, i.e. one needs to
see it in the diff anyway. Usually what we do is try to summarize, and
most importantly, explain the "why".

Also, it doesn't seem like the list covers every change anyway if that
was the intention, e.g. the removal of `--out-dir`.

> -rustdoc-quote: private rustc_target_flags = $(quote-flags)
> +rustdoc-quote: private rustc_target_flags = $(quote-flags) \
> +    --extern proc_macro2

Hmm... why is this needed? The variable already carries the flag, no?

> -               --out-dir $(objtree)/$(obj) -L$(objtree)/$(obj) \

This looks like an important removal that is not explained/mentioned elsewhere.

Also, is there a reason why we cannot keep the `-L` here instead of
adding it in every proc macro library?

> +    --extern pin_init_internal=$(abspath $(objtree)/$(obj)/$(libpin_init_internal_name)) \
> +    --extern macros=$(abspath $(objtree)/$(obj)/$(libmacros_name)) \
> +    $(call cfgs-to-flags,$(pin_init-cfgs)) \

Hmm... This special handling isn't great, and the fact that it means
hardcoding/duplicating `pin_init-flags`.

Should we move the proc macros too?

> -               --crate-type proc-macro -L$(objtree)/$(obj) \
> +               --crate-type proc-macro \
> +               -L$(objtree)/$(obj)/host \

Spurious newline added?

> -               @$(objtree)/include/generated/rustc_cfg $<
> +               @$(objtree)/include/generated/rustc_cfg \
> +               $(rustc_target_flags) \
> +               $<

Why is the variable moved here?

Thanks!

Cheers,
Miguel