NetBSD/powerpc cannot find crate zerofrom::ZeroFrom

[he32]

Hi, I'm in the process of cross-building rust 1.74.0 for the various NetBSD targets I do my best to maintain. So far I've crossed off armv6hf, armv7hf and sparc64 from the list as successfully cross-built. However, for some odd reason, NetBSD/powerpc refuses to build with an error which is new to me:

     Running `/usr/pkgsrc/wip/rust174/work/rustc-1.74.0-src/build/bootstrap/debug/rustc --crate-name yoke --edition=2021 /usr/pkgsrc/wip/rust174/work/rustc-1.74.0-src/vendor/yoke/src/lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts,future-incompat --crate-type lib --emit=dep-info,metadata,link -Copt-level=3 -C embed-bitcode=no --cfg 'feature="alloc"' --cfg 'feature="default"' --cfg 'feature="derive"' --cfg 'feature="zerofrom"' -Zunstable-options --check-cfg 'values(feature, "alloc", "default", "derive","serde", "zerofrom")' --check-cfg 'names()' --check-cfg 'values()' -C metadata=27459de9de92d894 -C extra-filename=-27459de9de92d894 --out-dir /usr/pkgsrc/wip/rust174/work/rustc-1.74.0-src/build/x86_64-unknown-netbsd/stage1-rustc/powerpc-unknown-netbsd/release/deps --target powerpc-unknown-netbsd -C linker=/usr/pkgsrc/wip/rust174/work/scripts/gcc-wrap -L dependency=/usr/pkgsrc/wip/rust174/work/rustc-1.74.0-src/build/x86_6
4-unknown-netbsd/stage1-rustc/powerpc-unknown-netbsd/release/deps -L dependency=/usr/pkgsrc/wip/rust174/work/rustc-1.74.0-src/build/x86_64-unknown-netbsd/stage1-rustc/release/deps --extern stable_deref_trait=/usr/pkgsrc/wip/rust174/work/rustc-1.74.0-src/build/x86_64-unknown-netbsd/stage1-rustc/powerpc-unknown-netbsd/release/deps/libstable_deref_trait-2720e75738c41cab.rmeta --extern yoke_derive=/usr/pkgsrc/wip/rust174/work/rustc-1.74.0-src/build/x86_64-unknown-netbsd/stage1-rustc/release/deps/libyoke_derive-41be1d13f87f0691.so --extern yoke_derive=/usr/pkgsrc/wip/rust174/work/rustc-1.74.0-src/build/x86_64-unknown-netbsd/stage1-rustc/powerpc-unknown-netbsd/release/deps/libyoke_derive-8b602905a7a5e9e1.so --extern zerofrom=/usr/pkgsrc/wip/rust174/work/rustc-1.74.0-src/build/x86_64-unknown-netbsd/stage1-rustc/powerpc-unknown-netbsd/release/deps/libzerofrom-ce3880fdde0ea386.rmeta --cap-lints allow --cfg=windows_raw_dylib -Csymbol-mangling-version=v0 -Zunstable-options '--check-cfg=values(bootstrap)' '--check-cfg=values(parallel_compiler)' '--check-cfg=values(target_os,"hurd")' '--check-cfg=values(no_btreemap_remove_entry)' '--check-cfg=values(crossbeam_loom)' '--check-cfg=values(span_locations)' '--check-cfg=values(rustix_use_libc)' '--check-cfg=values(emulate_second_only_system)' '--check-cfg=values(windows_raw_dylib)' -Zdual-proc-macros -Zmacro-backtrace -Clink-args=-Wl,-z,origin -Clink-args=-Wl,-rpath,/usr/pkg/lib -Zunstable-options -Csplit-debuginfo=off -Zunstable-options 'Wrustc::internal' -Cprefer-dynamic -Z binary-dep-depinfo`
error[E0463]: can't find crate for `zerofrom`
  --> /usr/pkgsrc/wip/rust174/work/rustc-1.74.0-src/vendor/yoke/src/lib.rs:65:5
   |
65 | use zerofrom::ZeroFrom;
   |     ^^^^^^^^ can't find crate

I find this odd since I have success for several other targets already, so there is evidence this isn't a generic NetBSD problem.

So ... at this moment I'm looking for clues as to what might be the cause of this problem for this particular target, and I'm receptive to suggestions as to what is actually going on here, and what to do to fix this.

[bjorn3]

Could you try building with RUSTC_LOG=rustc_metadata set as env var? You may want to compile without first and them once you get this build error compile again with it set to avoid getting spammed by log messages. (setting RUSTC_LOG doesn't invalidate build caches)

[he32]

Hm, I did a build with RUSTC_LOG=rustc_metadata set as env var, and then "of course", the cross-build succeeded. I repeated the cross-build for this particular target without this env var set, and then "of course" it succeeded again. So ... This appears to not be entirely reproducible / spurious. I'm inclined to close this issue as "not fully reproducible". Any other suggestions?

[bjorn3]

Closing this issue makes sense to me. If you ever hit it again, feel free to re-open.

[he32]

Agree to closing for now, will re-open if reproduced, and will then try RUSTC_LOG setting to see if this can be reproduced with more information.