On Sat, Apr 4, 2026 at 2:16 PM Mukesh Kumar Chaurasiya (IBM) <[email protected]> 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
