When compiling with -j1 flag in powerpc, the libproc_macro finds the
libcore.rmeta both in toolchain and local rust directory. libproc_macro
should use the toolchain provided libcore.rmeta.

So for this, make libproc_macro2 libquote and libsyn dependent on core.o
so that libcore.rmeta is generated after these 3 files are done
compiling.

Signed-off-by: Mukesh Kumar Chaurasiya (IBM) <mkchauras@gmail.com>
---
 rust/Makefile | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/rust/Makefile b/rust/Makefile
index 9801af2e1e02..8e62f6fcf94f 100644
--- a/rust/Makefile
+++ b/rust/Makefile
@@ -650,7 +650,8 @@ $(obj)/core.o: private skip_flags = $(core-skip_flags)
 $(obj)/core.o: private rustc_objcopy = $(foreach sym,$(redirect-intrinsics),--redefine-sym $(sym)=__rust$(sym))
 $(obj)/core.o: private rustc_target_flags = $(core-flags)
 $(obj)/core.o: $(RUST_LIB_SRC)/core/src/lib.rs \
-    $(wildcard $(objtree)/include/config/RUSTC_VERSION_TEXT) FORCE
+    $(wildcard $(objtree)/include/config/RUSTC_VERSION_TEXT) FORCE \
+    | $(obj)/libproc_macro2.rlib $(obj)/libquote.rlib $(obj)/libsyn.rlib FORCE
 	+$(call if_changed_rule,rustc_library)
 ifneq ($(or $(CONFIG_X86_64),$(CONFIG_X86_32)),)
 $(obj)/core.o: scripts/target.json
-- 
2.53.0

On Sun, Mar 29, 2026 at 6:03 PM Mukesh Kumar Chaurasiya (IBM)
<mkchauras@gmail.com> wrote:
>
> When compiling with -j1 flag in powerpc, the libproc_macro finds the
> libcore.rmeta both in toolchain and local rust directory. libproc_macro
> should use the toolchain provided libcore.rmeta.

By toolchain, do you mean the sysroot one or something else?

We should make it such that `rustc` does not try to use them to begin
with, e.g. we added `--sysroot=/dev/null` to prevent that in the past,
please see:

  71479eee9da8 ("rust: Suppress searching builtin sysroot")

In other words, we should try to avoid adding dependencies (even if
order-only) to workaround the issue, but instead we should get rid of
the root issue.

Otherwise, after a build, if we rebuild only one of them, wouldn't it
find again both? i.e. this is not really a "race condition".

From the original message, I see this was happening when building the
host libraries, because the targets happen to match, i.e. you are
doing a native build on powerpc, right?

Perhaps we could put the host `.rmeta`s separately, or something like that.

Thanks!

Cheers,
Miguel

On Sun, Mar 29, 2026 at 07:25:19PM +0200, Miguel Ojeda wrote:
> On Sun, Mar 29, 2026 at 6:03 PM Mukesh Kumar Chaurasiya (IBM)
> <mkchauras@gmail.com> wrote:
> >
> > When compiling with -j1 flag in powerpc, the libproc_macro finds the
> > libcore.rmeta both in toolchain and local rust directory. libproc_macro
> > should use the toolchain provided libcore.rmeta.
> 
> By toolchain, do you mean the sysroot one or something else?
> 
Hey Miguel,

yeah the sysroot one.
> We should make it such that `rustc` does not try to use them to begin
> with, e.g. we added `--sysroot=/dev/null` to prevent that in the past,
> please see:
> 
>   71479eee9da8 ("rust: Suppress searching builtin sysroot")
> 
> In other words, we should try to avoid adding dependencies (even if
> order-only) to workaround the issue, but instead we should get rid of
> the root issue.
> 
> Otherwise, after a build, if we rebuild only one of them, wouldn't it
> find again both? i.e. this is not really a "race condition".
> 
Yeah this makes sense.

> From the original message, I see this was happening when building the
> host libraries, because the targets happen to match, i.e. you are
> doing a native build on powerpc, right?
Yes we are doing a native powerpc build.
> 
> Perhaps we could put the host `.rmeta`s separately, or something like that.
I didn't understand this part, `.rmeta` for host are kept in sysroot
path, are we trying to change the sysroot directory?

Regards,
Mukesh
>
> Thanks!
> 
> Cheers,
> Miguel

On Sun Mar 29, 2026 at 6:25 PM BST, Miguel Ojeda wrote:
> On Sun, Mar 29, 2026 at 6:03 PM Mukesh Kumar Chaurasiya (IBM)
> <mkchauras@gmail.com> wrote:
>>
>> When compiling with -j1 flag in powerpc, the libproc_macro finds the
>> libcore.rmeta both in toolchain and local rust directory. libproc_macro
>> should use the toolchain provided libcore.rmeta.
>
> By toolchain, do you mean the sysroot one or something else?
>
> We should make it such that `rustc` does not try to use them to begin
> with, e.g. we added `--sysroot=/dev/null` to prevent that in the past,
> please see:
>
>   71479eee9da8 ("rust: Suppress searching builtin sysroot")
>
> In other words, we should try to avoid adding dependencies (even if
> order-only) to workaround the issue, but instead we should get rid of
> the root issue.
>
> Otherwise, after a build, if we rebuild only one of them, wouldn't it
> find again both? i.e. this is not really a "race condition".
>
> From the original message, I see this was happening when building the
> host libraries, because the targets happen to match, i.e. you are
> doing a native build on powerpc, right?
>
> Perhaps we could put the host `.rmeta`s separately, or something like that.

Yeah, we can either remove `-L$(objtree)/$(obj)` and specify `--extern
dep=path-to-dep`, or we can store host libraries to something like
`$(objtree)/$(obj)/host` and use that instead.

The latter should be an easier fix. Also, I can see that we're already having
`-L$(objtree)/$(obj)/test`.

Best,
Gary

On Sun, Mar 29, 2026 at 07:26:55PM +0100, Gary Guo wrote:
> On Sun Mar 29, 2026 at 6:25 PM BST, Miguel Ojeda wrote:
> > On Sun, Mar 29, 2026 at 6:03 PM Mukesh Kumar Chaurasiya (IBM)
> > <mkchauras@gmail.com> wrote:
> >>
> >> When compiling with -j1 flag in powerpc, the libproc_macro finds the
> >> libcore.rmeta both in toolchain and local rust directory. libproc_macro
> >> should use the toolchain provided libcore.rmeta.
> >
> > By toolchain, do you mean the sysroot one or something else?
> >
> > We should make it such that `rustc` does not try to use them to begin
> > with, e.g. we added `--sysroot=/dev/null` to prevent that in the past,
> > please see:
> >
> >   71479eee9da8 ("rust: Suppress searching builtin sysroot")
> >
> > In other words, we should try to avoid adding dependencies (even if
> > order-only) to workaround the issue, but instead we should get rid of
> > the root issue.
> >
> > Otherwise, after a build, if we rebuild only one of them, wouldn't it
> > find again both? i.e. this is not really a "race condition".
> >
> > From the original message, I see this was happening when building the
> > host libraries, because the targets happen to match, i.e. you are
> > doing a native build on powerpc, right?
> >
> > Perhaps we could put the host `.rmeta`s separately, or something like that.
> 
> Yeah, we can either remove `-L$(objtree)/$(obj)` and specify `--extern
> dep=path-to-dep`, or we can store host libraries to something like
> `$(objtree)/$(obj)/host` and use that instead.
> 
Oh now i understood what Miguel was trying to say. Thanks for the
explanation. 
> The latter should be an easier fix. Also, I can see that we're already having
> `-L$(objtree)/$(obj)/test`.
> 
I'll try this.

Regards,
Mukesh
> Best,
> Gary
>