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) > <[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). > 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
