I'm trying to build lang/rust on armv7, and it's failing very early in the build phase: ... install: copying file /construction/xports/lang/rust/work/bootstrap/share/man/man1/rustc.1 install: copying file /construction/xports/lang/rust/work/bootstrap/share/man/man1/rustdoc.1 rustc installed. -------------------------------------------------------------------------------- -- Phase: build -------------------------------------------------------------------------------- ===> Building for rust-1.79.0 unknown cpu type: armv7 Build completed unsuccessfully in 0:00:00 *** Error code 1 Stop. make: stopped in /xports/lang/rust
The build environment is a armv7 chroot on a aarch64 host, running FreeBSD 14.1-STABLE.
Created attachment 251805 [details] support armv7 in bootstrap.py tweak bootstrap.py to recognise armv7 as a valid CPU
Unfortunately, the armv7 1.78 cargo bootstrap is failing with a segfault: # /construction/xports/lang/rust/work/bootstrap/bin/cargo build --manifest-path /construction/xports/lang/rust/work/rustc-1.79.0-src/src/bootstrap/Cargo.toml --verbose --verbose --frozen Segmentation fault
It works here on real armv7 hw (no aarch64 in use). Do you know if it used to work?
Rust-1.80 fails to build on armv7-14.0 (in an armv7 jail on arm64 CURRENT): =======================<phase: build >============================ ===== env: NO_DEPENDS=yes USER=root UID=0 GID=0 ===> Building for rust-1.80.1 Building bootstrap running: /wrkdirs/usr/ports/lang/rust/work/bootstrap/bin/cargo build --manifest-path /wrkdirs/usr/ports/lang/rust/work/rustc-1.80.1-src/src/bootstrap/Cargo.toml --verbose --verbose --frozen Traceback (most recent call last): File "/wrkdirs/usr/ports/lang/rust/work/rustc-1.80.1-src/x.py", line 50, in <module> bootstrap.main() File "/wrkdirs/usr/ports/lang/rust/work/rustc-1.80.1-src/src/bootstrap/bootstrap.py", line 1191, in main bootstrap(args) File "/wrkdirs/usr/ports/lang/rust/work/rustc-1.80.1-src/src/bootstrap/bootstrap.py", line 1158, in bootstrap build.build_bootstrap() File "/wrkdirs/usr/ports/lang/rust/work/rustc-1.80.1-src/src/bootstrap/bootstrap.py", line 904, in build_bootstrap run(args, env=env, verbose=self.verbose, cwd=self.rust_root) File "/wrkdirs/usr/ports/lang/rust/work/rustc-1.80.1-src/src/bootstrap/bootstrap.py", line 186, in run raise RuntimeError(err) RuntimeError: failed to run: /wrkdirs/usr/ports/lang/rust/work/bootstrap/bin/cargo build --manifest-path /wrkdirs/usr/ports/lang/rust/work/rustc-1.80.1-src/src/bootstrap/Cargo.toml --verbose --verbose --frozen *** Error code 1 Stop. make: stopped in /usr/ports/lang/rust =>> Cleaning up wrkdir ===> Cleaning for rust-1.80.1 build of lang/rust | rust-1.80.1 ended at Fri Sep 13 15:53:47 CEST 2024 build time: 00:02:31 !!! build failure encountered !!! It has been quite a while since the last successful build.
Works fine on real armv7 board.
(In reply to Mikael Urankar from comment #6) Sounds like this might be another bug in our armv7 on aarch64 support. It is important that armv7 Rust can be built on an aarch64 board as that's what our package builders do. Doesn't mean it's not a bug, just maybe not in lang/rust.
CC cognet@ who worked out a previous issue of this kind. I can reproduce the issue on CURRENT.
This problem is different from the original one (unknown processor type: armv7) Bootstrap cargo is looking for rustc in the actual path, so it can't find lang/rust/work/bootstrap/bin/rustc executable. However, if a previous version of rust is installed on the system, bootstrap cargo will use it. I have no idea how to prepend lang/rust/work/bootstrap/bin to path in bootstrap stage of the build process, but the problem is now at least clear. The next question is whether rust make uses the correct binaries at different build stages...
Seems like it's a port bug after all. To reproduce, build with Poudriere or in an environment where rust is not already installed. If rust is already installed, the build succeeds. Not sure if this reproduces on native armv7.
(In reply to Robert Clausecker from comment #10) I've built rust *many* times with poudriere without any issue.
After another round of testing, I must apologize. The problem described above was caused by a stupid pilot error :( I can confirm that I can build the current version of rust on native armv7 and arm32, regardless of whether the previous version was installed or not. Once again a big sorry for the noise. Michal
I have updated my jail to 14.1 now that 14.0 is out of support, and the symptoms change. The build now proceeds further and crashes with a super weird clang exception: thread 'rustc' panicked at /wrkdirs/usr/ports/lang/rust-bootstrap/work-armv7/rustc-1.80.0-src/library/std/src/thread/local.rs:260:26: cannot access a Thread Local Storage value during or after destruction: AccessError stack backtrace: thread 'rustc' panicked at /wrkdirs/usr/ports/lang/rust-bootstrap/work-armv7/rustc-1.80.0-src/library/std/src/thread/local.rs:260:26: cannot access a Thread Local Storage value during or after destruction: AccessError stack backtrace: 0: rust_begin_unwind 1: core::panicking::panic_fmt 2: core::result::unwrap_failed 3: <rustc_middle::ty::adt::AdtDefData as rustc_data_structures::stable_hasher::HashStable<rustc_query_system::ich::hcx::StableHashingContext>>::hash_stable 4: <rustc_type_ir::ty_info::WithCachedTypeInfo<rustc_type_ir::ty_kind::TyKind<rustc_middle::ty::context::TyCtxt>> as rustc_data_structures::stable_hasher::HashStable<rustc_query_system::ich::hcx::StableHashingContext>>::hash_stable 5: rustc_symbol_mangling::legacy::mangle 6: rustc_symbol_mangling::symbol_name_provider [... omitted 2 frames ...] 7: rustc_middle::query::plumbing::query_get_at::<rustc_query_system::query::caches::DefaultCache<rustc_middle::ty::instance::Instance, rustc_middle::query::erase::Erased<[u8; 8]>>> 8: <rustc_middle::mir::mono::MonoItem>::symbol_name 9: <alloc::vec::Vec<(&rustc_middle::mir::mono::MonoItem, rustc_middle::ty::SymbolName)> as alloc::vec::spec_from_iter::SpecFromIter<(&rustc_middle::mir::mono::MonoItem, rustc_middle::ty::SymbolName), core::iter::adapters::map::Map<core::slice::iter::Iter<rustc_middle::mir::mono::MonoItem>, rustc_monomorphize::partitioning::assert_symbols_are_distinct<core::slice::iter::Iter<rustc_middle::mir::mono::MonoItem>>::{closure#0}>>>::from_iter 10: rustc_monomorphize::partitioning::assert_symbols_are_distinct::<core::slice::iter::Iter<rustc_middle::mir::mono::MonoItem>> 11: <rustc_data_structures::sync::parallel::ParallelGuard>::run::<(), rustc_monomorphize::partitioning::collect_and_partition_mono_items::{closure#0}::{closure#1}> 12: rustc_data_structures::sync::parallel::disabled::join::<rustc_monomorphize::partitioning::collect_and_partition_mono_items::{closure#0}::{closure#0}, rustc_monomorphize::partitioning::collect_and_partition_mono_items::{closure#0}::{closure#1}, &[rustc_middle::mir::mono::CodegenUnit], ()> 13: <rustc_session::session::Session>::time::<(&[rustc_middle::mir::mono::CodegenUnit], ()), rustc_monomorphize::partitioning::collect_and_partition_mono_items::{closure#0}> 14: rustc_monomorphize::partitioning::collect_and_partition_mono_items [... omitted 2 frames ...] 15: rustc_codegen_ssa::back::symbol_export::exported_symbols_provider_local [... omitted 2 frames ...] 16: <rustc_metadata::rmeta::encoder::EncodeContext>::encode_crate_root 17: rustc_metadata::rmeta::encoder::encode_metadata 18: rustc_metadata::fs::encode_and_write_metadata 19: rustc_interface::passes::start_codegen 20: <rustc_middle::ty::context::GlobalCtxt>::enter::<<rustc_interface::queries::Queries>::codegen_and_build_linker::{closure#0}, core::result::Result<rustc_interface::queries::Linker, rustc_span::ErrorGuaranteed>> 21: <rustc_interface::queries::Queries>::codegen_and_build_linker 22: <rustc_interface::interface::Compiler>::enter::<rustc_driver_impl::run_compiler::{closure#0}::{closure#1}, core::result::Result<core::option::Option<rustc_interface::queries::Linker>, rustc_span::ErrorGuaranteed>> 23: rustc_span::create_session_globals_then::<core::result::Result<(), rustc_span::ErrorGuaranteed>, rustc_interface::util::run_in_thread_with_globals<rustc_interface::interface::run_compiler<core::result::Result<(), rustc_span::ErrorGuaranteed>, rustc_driver_impl::run_compiler::{closure#0}>::{closure#1}, core::result::Result<(), rustc_span::ErrorGuaranteed>>::{closure#0}::{closure#0}::{closure#0}>
I still don't understand why it's a rust@ problem and affected to us?
(In reply to Mikael Urankar from comment #14) Because rust does not build? What else should be the problem?
(In reply to Robert Clausecker from comment #15) See comment 4 and comment 6?
(In reply to Mikael Urankar from comment #16) I do. There must be a reason why it builds for you but not for me.
(In reply to Robert Clausecker from comment #17) You do understand that this bug will never be fixed if it's not assigned to the correct team?
To exclude a setup error, I set up arm64 FreeBSD 14.1 on an Amazon AWS instance and tried to build rust for armv7 FreeBSD 14.1 there. Still fails the same way as on my other aarch64 machine. I do not know if this is a kernel issue or an issue in the Rust port. In any case, I have no idea how to fix it.