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

[Mukesh Kumar Chaurasiya]

On Sat, Apr 04, 2026 at 11:04:08PM +0200, Miguel Ojeda wrote:
> On Sat, Apr 4, 2026 at 2:16 PM Mukesh Kumar Chaurasiya (IBM)
> <mkchauras at gmail.com> 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).
> 
Yeah this makes sense. Will reword the whole thing and send out a new
revision.

> > - 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`.
>
Ohk, will rewrite this part also.

> > -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?
> 
Oh yeah. Will fix this.
> > -               --out-dir $(objtree)/$(obj) -L$(objtree)/$(obj) \
> 
> This looks like an important removal that is not explained/mentioned elsewhere.
> 
Ohk, will explain this in commit message.

> Also, is there a reason why we cannot keep the `-L` here instead of
> adding it in every proc macro library?
> 
Will move the `-L` here instead of each lib.
> > +    --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?
> 
Let me find a cleaner way to do this. Will do something about this in
next revision.

> > -               --crate-type proc-macro -L$(objtree)/$(obj) \
> > +               --crate-type proc-macro \
> > +               -L$(objtree)/$(obj)/host \
> 
> Spurious newline added?
> 
Will remove this.

> > -               @$(objtree)/include/generated/rustc_cfg $<
> > +               @$(objtree)/include/generated/rustc_cfg \
> > +               $(rustc_target_flags) \
> > +               $<
> 
> Why is the variable moved here?
> 
Will fix this too.

> Thanks!
> 
> Cheers,
> Miguel

Thanks for the detailed review.

Regards,
Mukesh