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.
(In reply to Robert Clausecker from comment #10) This #10 report prepdates the recent 1.82.0 of lang/rust (and its internal use of LLVM 19 by default). So far as I know, ampere2 has never shown the behaviors Robert has reported for its poudriere based builds. The recent: https://pkg-status.freebsd.org/ampere2/data/main-armv7-default/p711a2f7f1ca4_s0d965bc034/logs/rust-1.81.0.log is another example of a successful rust build on ampere2, a 1.81.0 example. =>> Building lang/rust build started at Fri Nov 1 05:01:04 UTC 2024 port directory: /usr/ports/lang/rust package name: rust-1.81.0 building for: FreeBSD main-armv7-default-job-10 15.0-CURRENT FreeBSD 15.0-CURRENT 1500026 arm maintained by: rust@FreeBSD.org Makefile datestamp: -rw-r--r-- 1 root wheel 11307 Oct 26 01:05 /usr/ports/lang/rust/Makefile Ports top last git commit: 711a2f7f1ca Ports top unclean checkout: no Port dir last git commit: 2501f5298c3 Port dir unclean checkout: no Poudriere version: poudriere-git-3.4.2 Host OSVERSION: 1500023 Jail OSVERSION: 1500026 Job Id: 10 . . . Similarly, prior to lang/rust 1.82.0 , I have not had problems with poudriere armv7 jails building lang/rust . (I do have a problem with lang/rust 1.82.0 in my usual environment. I've a separate bugzilla for that.) Based on ampere2 build behavior (avoiding involvement of my personalize environment for making judgments), the problem(s) Robert is reporting here seems specific to Robert's context somehow.
(In reply to Robert Clausecker from comment #19) Just for my edification: did the Amazon AWS testing use aarch64 hardware predating Graviton 4? --so that it supports at least EL0 aarch32/armv7 as well? (Graviton 4 appears not to but 3 and before appear to: I looked up a table summarizing such things.) I've never had access to an aarch64 that did not support aarch32/armv7 and so I've never seen the behaviors that result in FreeBSD when trying to do armv7 things in such a context.
(In reply to Mark Millard from comment #20) CORRECTION for the ampere* status for building lang/rust . . . My comments were based on a sampling bias: I use and pay attention to main [so: 15 for now] for the most part. This mean ampere2 only as well. https://portsfallout.com/fallout?port=lang%2Frust&maintainer=&env=releng-armv7-&category=&flavor= does indicate that *releng-armv7-* (so 133 and 141, default and quarterly, as things are now) are failing to build lang/rust on the ampere[13] buildlers and have been that way for some time. (I've not reviewed the log details vs. Robert's reports.) I'll note that port-package builders (ampere* included) run a main [so: 15] kernel but a poudriere/world-jail that is for the target system type and version. So: only main-armv7-default seems to be well behaved for lang/rust. None of the *releng-armv7-* seems to be well behaved for that. lang/rust armv7 packege building for releases is broken on FreeBSD and has been for some time. https://portsfallout.com/ does not present a long term history as far as I can tell, currently going back to early 2024-Jul. So I've no evidence of when before then the lang/rust build problems for releases started.
(In reply to Mark Millard from comment #22) Hi Mark, This could explain why nobody was able to reproduce the failures. I had only ever build tested for 14.1 and 13.3-RELEASE but never CURRENT (I don't test CURRENT for ports builds and don't run CURRENT in the jails I use for ports testing). Likewise, 14.1 was installed on the AWS instance I used to test build in addition to my usual ports box (my usual box runs 15-CURRENT on the host with 14.1/13.3 in the build jails). I tested 1.81.0 in the AWS instance and now just retested 1.82.0, which fails with a compiler crash as before: stack backtrace: 0: rust_begin_unwind 1: core::panicking::panic_fmt 2: core::cell::panic_already_borrowed 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_interface::queries::Linker>::codegen_and_build_linker 21: <rustc_middle::ty::context::GlobalCtxt>::enter::<rustc_driver_impl::run_compiler::{closure#0}::{closure#1}::{closure#6}, core::result::Result<core::option::Option<rustc_interface::queries::Linker>, rustc_span::ErrorGuaranteed>> 22: <rustc_interface::queries::QueryResult<&rustc_middle::ty::context::GlobalCtxt>>::enter::<core::result::Result<core::option::Option<rustc_interface::queries::Linker>, rustc_span::ErrorGuaranteed>, rustc_driver_impl::run_compiler::{closure#0}::{closure#1}::{closure#6}> 23: <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>> note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace. error: the compiler unexpectedly panicked. this is a bug.
(In reply to Robert Clausecker from comment #23) I've finally set up a stable/14 context (delayed by months from when I first started it). It is PkgBase aarch64 style and is based on earlier today. I've created a armv7 poudiere jail and it is working on building lang/rust . Like the system, it is is a PkgBase type of jail handling based on earlier today. I'm using the boot media on the Windows Dev Kit 2023. It failed so the issue is not the mix of a main [so: 15] kernel and a 14.* world: This failure has stable 14 everywhere, no use of FreeBSD main at all. For reference: [00:39:45] [01] [00:00:00] Building lang/rust | rust-1.82.0_1 [00:44:34] [01] [00:04:49] Finished lang/rust | rust-1.82.0_1: Failed: build The log file ends with: . . . =========================================================================== =======================<phase: build >============================ ===== env: NO_DEPENDS=yes USER=root UID=0 GID=0 ===> Building for rust-1.82.0_1 Building bootstrap running: /wrkdirs/usr/ports/lang/rust/work/bootstrap/bin/cargo build --manifest-path /wrkdirs/usr/ports/lang/rust/work/rustc-1.82.0-src/src/bootstrap/Cargo.toml --verbose --verbose --frozen Traceback (most recent call last): File "/wrkdirs/usr/ports/lang/rust/work/rustc-1.82.0-src/x.py", line 50, in <module> bootstrap.main() File "/wrkdirs/usr/ports/lang/rust/work/rustc-1.82.0-src/src/bootstrap/bootstrap.py", line 1208, in main bootstrap(args) File "/wrkdirs/usr/ports/lang/rust/work/rustc-1.82.0-src/src/bootstrap/bootstrap.py", line 1175, in bootstrap build.build_bootstrap() File "/wrkdirs/usr/ports/lang/rust/work/rustc-1.82.0-src/src/bootstrap/bootstrap.py", line 921, in build_bootstrap run(args, env=env, verbose=self.verbose, cwd=self.rust_root) File "/wrkdirs/usr/ports/lang/rust/work/rustc-1.82.0-src/src/bootstrap/bootstrap.py", line 195, 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.82.0-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.82.0_1 build of lang/rust | rust-1.82.0_1 ended at Tue Nov 12 01:11:11 UTC 2024 build time: 00:05:03 !!! build failure encountered !!! As I remember, that matches the kind of errors shown on the official build server logs. (The WinDevKit23 takes longer to get to that point.) I'll have it generate a tar to expand into a /wrkdirs . (I normally have that disabled.)
(In reply to Mark Millard from comment #24) Looking around in the /wrkdirs/usr/ports/lang/rust/work/ area shows that there is a: # file /wrkdirs/usr/ports/lang/rust/work/rustc-1.82.0-src/cargo.core /wrkdirs/usr/ports/lang/rust/work/rustc-1.82.0-src/cargo.core: ELF 32-bit LSB core file, ARM, EABI5 version 1 (FreeBSD), FreeBSD-style, from '/wrkdirs/usr/ports/lang/rust/work/bootstrap/bin/cargo build --manifest-path /wrk', pid=59746 # ls -lodT /wrkdirs/usr/ports/lang/rust/work/rustc-1.82.0-src/cargo.core -rw------- 1 root wheel - 82173952 Nov 11 17:33:25 2024 /wrkdirs/usr/ports/lang/rust/work/rustc-1.82.0-src/cargo.core file. gdb reports: Reading symbols from /wrkdirs/usr/ports/lang/rust/work/bootstrap/bin/cargo... [New LWP 100351] Core was generated by `/wrkdirs/usr/ports/lang/rust/work/bootstrap/bin/cargo build --manifest-path /wrk'. Program terminated with signal SIGSEGV, Segmentation fault. Address not mapped to object. #0 0x0240a200 in ?? () (gdb) bt #0 0x0240a200 in ?? () #1 0x00000008 in ?? () Backtrace stopped: previous frame identical to this frame (corrupt stack?) (gdb) quit So, guessing after looking around, I tried: # env PATH="$PATH:/wrkdirs/usr/ports/lang/rust/work/bootstrap/bin" gdb /wrkdirs/usr/ports/lang/rust/work/bootstrap/bin/cargo . . . (gdb) run build --manifest-path /wrkdirs/usr/ports/lang/rust/work/rustc-1.82.0-src/src/bootstrap/Cargo.toml --verbose --verbose --frozen Starting program: /wrkdirs/usr/ports/lang/rust/work/bootstrap/bin/cargo build --manifest-path /wrkdirs/usr/ports/lang/rust/work/rustc-1.82.0-src/src/bootstrap/Cargo.toml --verbose --verbose --frozen [Detaching after vfork from child process 98679] [Detaching after vfork from child process 98680] [Detaching after vfork from child process 98681] [Detaching after vfork from child process 98682] thread 'main' panicked at /wrkdirs/usr/ports/lang/rust-bootstrap/work-armv7/rustc-1.81.0-src/vendor/regex-automata-0.4.6/src/hybrid/dfa.rs:1223:30: index out of bounds: the len is 0 but the index is 3 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace [Inferior 1 (process 98678) exited with code 0145] So . . . # env RUST_BACKTRACE=1 PATH="$PATH:/wrkdirs/usr/ports/lang/rust/work/bootstrap/bin" gdb /wrkdirs/usr/ports/lang/rust/work/bootstrap/bin/cargo . . . Reading symbols from /wrkdirs/usr/ports/lang/rust/work/bootstrap/bin/cargo... (gdb) run build --manifest-path /wrkdirs/usr/ports/lang/rust/work/rustc-1.82.0-src/src/bootstrap/Cargo.toml --verbose --verbose --frozen Starting program: /wrkdirs/usr/ports/lang/rust/work/bootstrap/bin/cargo build --manifest-path /wrkdirs/usr/ports/lang/rust/work/rustc-1.82.0-src/src/bootstrap/Cargo.toml --verbose --verbose --frozen Program received signal SIGSEGV, Segmentation fault. Address not mapped to object. 0x0240a200 in regex_automata::hybrid::search::find_overlapping_fwd () (gdb) bt #0 0x0240a200 in regex_automata::hybrid::search::find_overlapping_fwd () #1 0x023d2c44 in <regex_automata::meta::wrappers::HybridEngine>::try_which_overlapping_matches () #2 0x023cbc7c in <regex_automata::meta::strategy::Core as regex_automata::meta::strategy::Strategy>::which_overlapping_matches () #3 0x02394628 in <globset::GlobSet>::matches_candidate_into () #4 0x01b654ec in <ignore::gitignore::Gitignore>::matched_stripped::<&std::path::Path> () #5 0x01b658a8 in <ignore::gitignore::Gitignore>::matched_path_or_any_parents::<&std::path::Path> () #6 0x01acf714 in cargo::sources::path::_list_files::{closure#1} () #7 0x01ad1180 in cargo::sources::path::list_files_walk () #8 0x01acecbc in cargo::sources::path::list_files () #9 0x01ad16e0 in cargo::sources::path::last_modified_file () #10 0x01acc208 in <cargo::sources::path::PathSource as cargo::sources::source::Source>::fingerprint () #11 0x01832524 in cargo::core::compiler::fingerprint::calculate_run_custom_build::{closure#0} () #12 0x017f7410 in <cargo::core::compiler::fingerprint::build_script_local_fingerprints::{closure#1} as core::ops::function::FnOnce<(&cargo::core::compiler::custom_build::BuildDeps, core::option::Option<&dyn core::ops::function::Fn<(), Output = core::result::Result<alloc::string::String, anyhow::Error>>>)>>::call_once::{shim:vtable#0} () #13 0x0182d4dc in cargo::core::compiler::fingerprint::calculate () #14 0x0182cf40 in <cargo::core::compiler::fingerprint::DepFingerprint>::new () #15 0x01aadc64 in <alloc::vec::into_iter::IntoIter<cargo::core::compiler::unit_graph::UnitDep> as core::iter::traits::iterator::Iterator>::try_fold::<(), core::iter::adapters::filter::filter_try_fold<cargo::core::compiler::unit_graph::UnitDep, (), core::ops::control_flow::ControlFlow<core::ops::control_flow::ControlFlow<cargo::core::compiler::fingerprint::DepFingerprint>>, cargo::core::compiler::fingerprint::calculate_normal::{closure#0}, core::iter::adapters::map::map_try_fold<cargo::core::compiler::unit_graph::UnitDep, core::result::Result<cargo::core::compiler::fingerprint::DepFingerprint, anyhow::Error>, (), core::ops::control_flow::ControlFlow<core::ops::control_flow::ControlFlow<cargo::core::compiler::fingerprint::DepFingerprint>>, cargo::core::compiler::fingerprint::calculate_normal::{closure#1}, <core::iter::adapters::GenericShunt<core::iter::adapters::map::Map<core::iter::adapters::filter::Filter<alloc::vec::into_iter::IntoIter<cargo::core::compiler::unit_graph::UnitDep>, cargo::core::compiler::fingerprint::calculate_normal::{closure#0}>, cargo::core::compiler::fingerprint::calculate_normal::{closure#1}>, core::result::Result<core::convert::Infallible, anyhow::Error>> as core::iter::traits::iterator::Iterator>::try_fold<(), core::iter::traits::iterator::Iterator::try_for_each::call<cargo::core::compiler::fingerprint::DepFingerprint, core::ops::control_flow::ControlFlow<cargo::core::compiler::fingerprint::DepFingerprint>, core::ops::control_flow::ControlFlow<cargo::core::compiler::fingerprint::DepFingerprint>::Break>::{closure#0}, core::ops::control_flow::ControlFlow<cargo::core::compiler::fingerprint::DepFingerprint>>::{closure#0}>::{closure#0}>::{closure#0}, core::ops::control_flow::ControlFlow<core::ops::control_flow::ControlFlow<cargo::core::compiler::fingerprint::DepFingerprint>>> () #16 0x0179444c in core::iter::adapters::try_process::<core::iter::adapters::map::Map<core::iter::adapters::filter::Filter<alloc::vec::into_iter::IntoIter<cargo::core::compiler::unit_graph::UnitDep>, cargo::core::compiler::fingerprint::calculate_normal::{closure#0}>, cargo::core::compiler::fingerprint::calculate_normal::{closure#1}>, cargo::core::compiler::fingerprint::DepFingerprint, core::result::Result<core::convert::Infallible, anyhow::Error>, <core::result::Result<alloc::vec::Vec<cargo::core::compiler::fingerprint::DepFingerprint>, anyhow::Error> as core::iter::traits::collect::FromIterator<core::result::Result<cargo::core::compiler::fingerprint::DepFingerprint, anyhow::Error>>>::from_iter<core::iter::adapters::map::Map<core::iter::adapters::filter::Filter<alloc::vec::into_iter::IntoIter<cargo::core::compiler::unit_graph::UnitDep>, cargo::core::compiler::fingerprint::calculate_normal::{closure#0}>, cargo::core::compiler::fingerprint::calculate_normal::{closure#1}>>::{closure#0}, alloc::vec::Vec<cargo::core::compiler::fingerprint::DepFingerprint>> () #17 0x0182d590 in cargo::core::compiler::fingerprint::calculate () #18 0x018482d4 in cargo::core::compiler::fingerprint::prepare_target () #19 0x01b60780 in cargo::core::compiler::compile () #20 0x01979b3c in <cargo::core::compiler::build_runner::BuildRunner>::compile () #21 0x0188f644 in cargo::ops::cargo_compile::compile_ws () #22 0x01871db0 in cargo::ops::cargo_compile::compile () #23 0x013e59dc in cargo::commands::build::exec () #24 0x013d95f4 in <cargo::cli::Exec>::exec () #25 0x013d6c24 in cargo::cli::main () #26 0x0141c6d8 in cargo::main () #27 0x013fdd2c in std::sys::backtrace::__rust_begin_short_backtrace::<fn(), ()> () #28 0x0140d4dc in std::rt::lang_start::<()>::{closure#0} () #29 0x02525f38 in std::rt::lang_start_internal () #30 0x0141fee4 in main () I'm not familiar with any of that --or rust in general. So I stop here for this context. I've no clue if a native stable/14 armv7 system (no aarch64 involved) would get similar results or not compared to the jail/chroot results explored above on aarch64 that has aarch32/armv7 support.
(In reply to Mark Millard from comment #25) It would be easy to miss, so: Notice the "lang/rust-bootstrap/" for "thread 'main' panicked at" in my report: lang/rust-bootstrap/work-armv7/rustc-1.81.0-src/vendor/regex-automata-0.4.6/src/hybrid/dfa.rs:1223:30 It is not the same code in lang/rust-bootstrap/, but Robert's comment #13 also reports a lang/rust-bootstrap/ related path: lang/rust-bootstrap/work-armv7/rustc-1.80.0-src/library/std/src/thread/local.rs:260:26
I have confirmed the target_env="gnu" problem in the stable/14 context for that attempt to build lang/rust 1.82.0 . The bootstrap rustc report is: # /wrkdirs/usr/ports/lang/rust/work/bootstrap/bin/rustc --print=cfg debug_assertions panic="unwind" target_abi="eabihf" target_arch="arm" target_endian="little" target_env="gnu" target_family="unix" target_has_atomic="16" target_has_atomic="32" target_has_atomic="64" target_has_atomic="8" target_has_atomic="ptr" target_os="freebsd" target_pointer_width="32" target_vendor="unknown" unix
Which is exactly what rustc reports on 15-current. Why do you think that's a problem?
(In reply to Michal Meloun from comment #28) rustc on current for armv7 is also messed up by target_env="gnu" selecting inappropriate (linux) conditional compilation code (mixed with also selecting the correct freebsd conditional compilation code while trying to compile for FreeBSD: error[E0428]: the name `type_of_thread_id` is defined multiple times --> /rust/deps/nix-0.29.0/src/sys/signal.rs:1110:1 | 1107 | pub type type_of_thread_id = libc::lwpid_t; | ------------------------------------------- previous definition of the type `type_of_thread_id` here ... 1110 | pub type type_of_thread_id = libc::pid_t; | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ `type_of_thread_id` redefined here | = note: `type_of_thread_id` must be defined only once in the type namespace of this module . . . error[E0609]: no field `sigev_notify_thread_id` on type `signal::sigevent::ffi::sigevent` --> /rust/deps/nix-0.29.0/src/sys/signal.rs:1364:25 | 1364 | sev.sigev_notify_thread_id = thread_id; | ^^^^^^^^^^^^^^^^^^^^^^ unknown field | = note: available fields are: `sigev_notify`, `sigev_signo`, `sigev_value`, `_sigev_un` In other words, the rust source code contains the assumption that target_env="gnu" conditional compilation tests imply linux or glibc or the like as the context. FreeBSD is not such a "GNU platform". (Terminology from the later quote.) FreeBSD's lang/rust port has been patched to not have that string but various bootstraps were not built that way (yet). (Others figured out the "gnu" problem before I was involved.) QUOTE target_env Key-value option set with further disambiguating information about the target platform with information about the ABI or libc used. For historical reasons, this value is only defined as not the empty-string when actually needed for disambiguation. Thus, for example, on many GNU platforms, this value will be empty. This value is similar to the fourth element of the platform’s target triple. One difference is that embedded ABIs such as gnueabihf will simply define target_env as "gnu". Example values: "" "gnu" "msvc" "musl" "sgx" END QUOTE So far as I can tell freebsd does not need target_env for any disambiguation given: target_abi="eabihf" target_arch="arm" target_os="freebsd" (Even target_abi="eabihf" looks to be redundant by that sort of criteria. But I do not find any important use of Conditional Compilation based on target_abi="eabihf" in the lang/rust related source code that I searched.) There is lots of use of target_env="gnu" based conditional compilation in what I searched: # grep -r 'cfg.*target_env.*"gnu"' /wrkdirs/usr/ports/lang/rust/work/ | wc -l 303 # grep -r 'cfg.*target_env.*"gnu"' /wrkdirs/usr/ports/lang/rust/work/ | grep -v target_abi | wc -l 301 (So, most target_env="gnu" use for conditional compilation is independent of target_abi .) # grep -r 'cfg.*target_env.*"gnu"' /wrkdirs/usr/ports/lang/rust/work/ | grep -v target_os | wc -l 193 (So, a lot of target_env="gnu" use for conditional compilation is independent of target_os .) (Note: I looked at the output texts as well --but I'm no rust expert.)
Bug #282663 has a possible fix for the issue. Further discussion there. *** This bug has been marked as a duplicate of bug 282663 ***