[bootstrap] Don't reverse the order of dylib search path entries by jnkel · Pull Request #161377 · rust-lang/rust

jnkel · 2026-08-19T23:16:26Z

The add_dylib_path helper function prepends paths to the beginning of the dynamic linker search path, but it reverses their order while doing so. This is surprising and undocumented, and seems to be unexpected by several callers of this function.

Particularly, rustc_lib_paths appends the ci-llvm path to the list it returns; reversing the order puts ci-llvm at a higher priority than the compiler's lib directory. On my system, this currently causes ./x test to fail (when building the unstable book), because the stage0 compiler is run using CI LLVM instead of stage0 LLVM (which are currently different because stage0 is on LLVM 22 while main is on LLVM 23).

Might be worth a try build as this change could potentially cause issues if there is somewhere we depend on this ordering reversal. I checked all the call-sites (and ran ./x test locally) and I don't think anyone intentionally relied on the ordering being reversed. I did find one snippet that concerned me (from #144303, cc @Kobzol):

rust/src/bootstrap/src/core/build_steps/test.rs

Lines 437 to 448 in f7d782a

    
           // The `cargo` command configured above has dylib dir path set to the `build_compiler`'s 
        
           // libdir. That causes issues in cargo test, because the programs that cargo compiles are 
        
           // incorrectly picking that libdir, even though they should be picking the 
        
           // `tested_compiler`'s libdir. We thus have to override the precedence here. 
        
           let mut existing_dylib_paths = cargo 
        
               .get_envs() 
        
               .find(|(k, _)| *k == OsStr::new(dylib_path_var())) 
        
               .and_then(|(_, v)| v) 
        
               .map(|value| split_paths(value).collect::<Vec<PathBuf>>()) 
        
               .unwrap_or_default(); 
        
           existing_dylib_paths.insert(0, builder.rustc_libdir(tested_compiler)); 
        
           add_dylib_path(existing_dylib_paths, &mut cargo);

The comment states we're inserting builder.rustc_libdir(tested_compiler) at the highest priority in the search path, but because add_dylib_path reversed the ordering, it's actually inserted at the lowest priority. I don't know how to reproduce the issue this was supposed to fix, so I can't be sure that this PR doesn't cause a regression.

Follow-up to #161335. r? @jieyouxu

Kobzol · 2026-08-20T06:21:15Z

The code in add_dylib is 11 years old and comes from bootstrap's first Rust commit. I agree that what you describe makes more sense.

Also, this is such a mess.. the ci-llvm directory really shouldn't be added in this function, that's super ad-hoc.

jieyouxu · 2026-08-25T09:43:32Z

(I'll look at this on Friday)

jieyouxu

Thanks. I did some history digging and could not find why this needed to be reversed. This order looks more correct to me.

@bors r+ rollup

View changes since this review

rust-bors · 2026-08-28T09:44:30Z

📌 Commit 67e8a19 has been approved by jieyouxu

It is now in the queue for this repository.

@Kobzol

…eyouxu [bootstrap] Don't reverse the order of dylib search path entries The `add_dylib_path` helper function prepends paths to the beginning of the dynamic linker search path, but it reverses their order while doing so. This is surprising and undocumented, and seems to be unexpected by several callers of this function. Particularly, [`rustc_lib_paths`](https://github.com/rust-lang/rust/blob/f7d782a3be46d6bb4b9792fe69a61db389ba1769/src/bootstrap/src/core/builder/mod.rs#L1375) appends the `ci-llvm` path to the list it returns; reversing the order puts `ci-llvm` at a higher priority than the compiler's lib directory. On my system, this currently causes `./x test` to fail (when building the unstable book), because the stage0 compiler is run using CI LLVM instead of stage0 LLVM (which are currently different because stage0 is on LLVM 22 while main is on LLVM 23). Might be worth a try build as this change could potentially cause issues if there is somewhere we depend on this ordering reversal. I checked all the call-sites (and ran `./x test` locally) and I don't think anyone *intentionally* relied on the ordering being reversed. I did find one snippet that concerned me (from rust-lang#144303, cc @Kobzol): https://github.com/rust-lang/rust/blob/f7d782a3be46d6bb4b9792fe69a61db389ba1769/src/bootstrap/src/core/build_steps/test.rs#L437-L448 The comment states we're inserting `builder.rustc_libdir(tested_compiler)` at the highest priority in the search path, but because `add_dylib_path` reversed the ordering, it's actually inserted at the *lowest* priority. I don't know how to reproduce the issue this was supposed to fix, so I can't be sure that this PR doesn't cause a regression. Follow-up to rust-lang#161335. r? @jieyouxu

@Kobzol

…eyouxu [bootstrap] Don't reverse the order of dylib search path entries The `add_dylib_path` helper function prepends paths to the beginning of the dynamic linker search path, but it reverses their order while doing so. This is surprising and undocumented, and seems to be unexpected by several callers of this function. Particularly, [`rustc_lib_paths`](https://github.com/rust-lang/rust/blob/f7d782a3be46d6bb4b9792fe69a61db389ba1769/src/bootstrap/src/core/builder/mod.rs#L1375) appends the `ci-llvm` path to the list it returns; reversing the order puts `ci-llvm` at a higher priority than the compiler's lib directory. On my system, this currently causes `./x test` to fail (when building the unstable book), because the stage0 compiler is run using CI LLVM instead of stage0 LLVM (which are currently different because stage0 is on LLVM 22 while main is on LLVM 23). Might be worth a try build as this change could potentially cause issues if there is somewhere we depend on this ordering reversal. I checked all the call-sites (and ran `./x test` locally) and I don't think anyone *intentionally* relied on the ordering being reversed. I did find one snippet that concerned me (from rust-lang#144303, cc @Kobzol): https://github.com/rust-lang/rust/blob/f7d782a3be46d6bb4b9792fe69a61db389ba1769/src/bootstrap/src/core/build_steps/test.rs#L437-L448 The comment states we're inserting `builder.rustc_libdir(tested_compiler)` at the highest priority in the search path, but because `add_dylib_path` reversed the ordering, it's actually inserted at the *lowest* priority. I don't know how to reproduce the issue this was supposed to fix, so I can't be sure that this PR doesn't cause a regression. Follow-up to rust-lang#161335. r? @jieyouxu

@Kobzol

…eyouxu [bootstrap] Don't reverse the order of dylib search path entries The `add_dylib_path` helper function prepends paths to the beginning of the dynamic linker search path, but it reverses their order while doing so. This is surprising and undocumented, and seems to be unexpected by several callers of this function. Particularly, [`rustc_lib_paths`](https://github.com/rust-lang/rust/blob/f7d782a3be46d6bb4b9792fe69a61db389ba1769/src/bootstrap/src/core/builder/mod.rs#L1375) appends the `ci-llvm` path to the list it returns; reversing the order puts `ci-llvm` at a higher priority than the compiler's lib directory. On my system, this currently causes `./x test` to fail (when building the unstable book), because the stage0 compiler is run using CI LLVM instead of stage0 LLVM (which are currently different because stage0 is on LLVM 22 while main is on LLVM 23). Might be worth a try build as this change could potentially cause issues if there is somewhere we depend on this ordering reversal. I checked all the call-sites (and ran `./x test` locally) and I don't think anyone *intentionally* relied on the ordering being reversed. I did find one snippet that concerned me (from rust-lang#144303, cc @Kobzol): https://github.com/rust-lang/rust/blob/f7d782a3be46d6bb4b9792fe69a61db389ba1769/src/bootstrap/src/core/build_steps/test.rs#L437-L448 The comment states we're inserting `builder.rustc_libdir(tested_compiler)` at the highest priority in the search path, but because `add_dylib_path` reversed the ordering, it's actually inserted at the *lowest* priority. I don't know how to reproduce the issue this was supposed to fix, so I can't be sure that this PR doesn't cause a regression. Follow-up to rust-lang#161335. r? @jieyouxu

…uwer Rollup of 15 pull requests Successful merges: - #160170 (Refactored docs for `std::fs::set_permissions_nofollow` + fix BSD-based systems to use fchmodat with AT_SYMLINK_NOFOLLOW flag) - #160594 (attach global target features to module-level assembly) - #161858 (fix ICE in generic_const_parameter_types with inherents) - #161353 (Add test for parallel compiler reproducible build) - #161377 ([bootstrap] Don't reverse the order of dylib search path entries) - #161804 (Document PartialOrd behavior for Option<T> where T: PartialOrd) - #161865 (loongarch: support passing `u128`/`i128` to inline assembly) - #161877 (Do not load macro metadata for local definitions in rustdoc) - #161880 (fix rustc_lint_defs doctest issues) - #161883 (better deal with internal features being injected into doctests) - #161887 (std: uefi: fix File::seek returning the EOF sentinel) - #161897 (Reject contract attributes without arguments) - #161909 (Report the configured Polonius default in -Z help) - #161910 (Add rustdoc-html regression test for generated macro) - #161914 (Retroactively add relnotes for `bool::{ok_or,ok_or_else}` (1.98.0))

@Kobzol

…eyouxu [bootstrap] Don't reverse the order of dylib search path entries The `add_dylib_path` helper function prepends paths to the beginning of the dynamic linker search path, but it reverses their order while doing so. This is surprising and undocumented, and seems to be unexpected by several callers of this function. Particularly, [`rustc_lib_paths`](https://github.com/rust-lang/rust/blob/f7d782a3be46d6bb4b9792fe69a61db389ba1769/src/bootstrap/src/core/builder/mod.rs#L1375) appends the `ci-llvm` path to the list it returns; reversing the order puts `ci-llvm` at a higher priority than the compiler's lib directory. On my system, this currently causes `./x test` to fail (when building the unstable book), because the stage0 compiler is run using CI LLVM instead of stage0 LLVM (which are currently different because stage0 is on LLVM 22 while main is on LLVM 23). Might be worth a try build as this change could potentially cause issues if there is somewhere we depend on this ordering reversal. I checked all the call-sites (and ran `./x test` locally) and I don't think anyone *intentionally* relied on the ordering being reversed. I did find one snippet that concerned me (from rust-lang#144303, cc @Kobzol): https://github.com/rust-lang/rust/blob/f7d782a3be46d6bb4b9792fe69a61db389ba1769/src/bootstrap/src/core/build_steps/test.rs#L437-L448 The comment states we're inserting `builder.rustc_libdir(tested_compiler)` at the highest priority in the search path, but because `add_dylib_path` reversed the ordering, it's actually inserted at the *lowest* priority. I don't know how to reproduce the issue this was supposed to fix, so I can't be sure that this PR doesn't cause a regression. Follow-up to rust-lang#161335. r? @jieyouxu

…uwer Rollup of 16 pull requests Successful merges: - #160170 (Refactored docs for `std::fs::set_permissions_nofollow` + fix BSD-based systems to use fchmodat with AT_SYMLINK_NOFOLLOW flag) - #161945 (std: optimise IO error formatting) - #160594 (attach global target features to module-level assembly) - #161577 (implement [u8]::split_ascii_whitespace) - #161858 (fix ICE in generic_const_parameter_types with inherents) - #161377 ([bootstrap] Don't reverse the order of dylib search path entries) - #161804 (Document PartialOrd behavior for Option<T> where T: PartialOrd) - #161865 (loongarch: support passing `u128`/`i128` to inline assembly) - #161877 (Do not load macro metadata for local definitions in rustdoc) - #161880 (fix rustc_lint_defs doctest issues) - #161883 (better deal with internal features being injected into doctests) - #161887 (std: uefi: fix File::seek returning the EOF sentinel) - #161897 (Reject contract attributes without arguments) - #161909 (Report the configured Polonius default in -Z help) - #161910 (Add rustdoc-html regression test for generated macro) - #161914 (Retroactively add relnotes for `bool::{ok_or,ok_or_else}` (1.98.0))

@Kobzol

…eyouxu [bootstrap] Don't reverse the order of dylib search path entries The `add_dylib_path` helper function prepends paths to the beginning of the dynamic linker search path, but it reverses their order while doing so. This is surprising and undocumented, and seems to be unexpected by several callers of this function. Particularly, [`rustc_lib_paths`](https://github.com/rust-lang/rust/blob/f7d782a3be46d6bb4b9792fe69a61db389ba1769/src/bootstrap/src/core/builder/mod.rs#L1375) appends the `ci-llvm` path to the list it returns; reversing the order puts `ci-llvm` at a higher priority than the compiler's lib directory. On my system, this currently causes `./x test` to fail (when building the unstable book), because the stage0 compiler is run using CI LLVM instead of stage0 LLVM (which are currently different because stage0 is on LLVM 22 while main is on LLVM 23). Might be worth a try build as this change could potentially cause issues if there is somewhere we depend on this ordering reversal. I checked all the call-sites (and ran `./x test` locally) and I don't think anyone *intentionally* relied on the ordering being reversed. I did find one snippet that concerned me (from rust-lang#144303, cc @Kobzol): https://github.com/rust-lang/rust/blob/f7d782a3be46d6bb4b9792fe69a61db389ba1769/src/bootstrap/src/core/build_steps/test.rs#L437-L448 The comment states we're inserting `builder.rustc_libdir(tested_compiler)` at the highest priority in the search path, but because `add_dylib_path` reversed the ordering, it's actually inserted at the *lowest* priority. I don't know how to reproduce the issue this was supposed to fix, so I can't be sure that this PR doesn't cause a regression. Follow-up to rust-lang#161335. r? @jieyouxu

…uwer Rollup of 16 pull requests Successful merges: - #161945 (std: optimise IO error formatting) - #160594 (attach global target features to module-level assembly) - #161577 (implement [u8]::split_ascii_whitespace) - #161858 (fix ICE in generic_const_parameter_types with inherents) - #161377 ([bootstrap] Don't reverse the order of dylib search path entries) - #161702 (Use `drop_guard` in some places in {core,alloc,std}) - #161804 (Document PartialOrd behavior for Option<T> where T: PartialOrd) - #161865 (loongarch: support passing `u128`/`i128` to inline assembly) - #161877 (Do not load macro metadata for local definitions in rustdoc) - #161880 (fix rustc_lint_defs doctest issues) - #161883 (better deal with internal features being injected into doctests) - #161887 (std: uefi: fix File::seek returning the EOF sentinel) - #161897 (Reject contract attributes without arguments) - #161909 (Report the configured Polonius default in -Z help) - #161910 (Add rustdoc-html regression test for generated macro) - #161914 (Retroactively add relnotes for `bool::{ok_or,ok_or_else}` (1.98.0))

@Kobzol

…eyouxu [bootstrap] Don't reverse the order of dylib search path entries The `add_dylib_path` helper function prepends paths to the beginning of the dynamic linker search path, but it reverses their order while doing so. This is surprising and undocumented, and seems to be unexpected by several callers of this function. Particularly, [`rustc_lib_paths`](https://github.com/rust-lang/rust/blob/f7d782a3be46d6bb4b9792fe69a61db389ba1769/src/bootstrap/src/core/builder/mod.rs#L1375) appends the `ci-llvm` path to the list it returns; reversing the order puts `ci-llvm` at a higher priority than the compiler's lib directory. On my system, this currently causes `./x test` to fail (when building the unstable book), because the stage0 compiler is run using CI LLVM instead of stage0 LLVM (which are currently different because stage0 is on LLVM 22 while main is on LLVM 23). Might be worth a try build as this change could potentially cause issues if there is somewhere we depend on this ordering reversal. I checked all the call-sites (and ran `./x test` locally) and I don't think anyone *intentionally* relied on the ordering being reversed. I did find one snippet that concerned me (from rust-lang#144303, cc @Kobzol): https://github.com/rust-lang/rust/blob/f7d782a3be46d6bb4b9792fe69a61db389ba1769/src/bootstrap/src/core/build_steps/test.rs#L437-L448 The comment states we're inserting `builder.rustc_libdir(tested_compiler)` at the highest priority in the search path, but because `add_dylib_path` reversed the ordering, it's actually inserted at the *lowest* priority. I don't know how to reproduce the issue this was supposed to fix, so I can't be sure that this PR doesn't cause a regression. Follow-up to rust-lang#161335. r? @jieyouxu

Rollup of 17 pull requests Successful merges: - #161945 (std: optimise IO error formatting) - #160594 (attach global target features to module-level assembly) - #161577 (implement [u8]::split_ascii_whitespace) - #161858 (fix ICE in generic_const_parameter_types with inherents) - #161377 ([bootstrap] Don't reverse the order of dylib search path entries) - #161804 (Document PartialOrd behavior for Option<T> where T: PartialOrd) - #161865 (loongarch: support passing `u128`/`i128` to inline assembly) - #161877 (Do not load macro metadata for local definitions in rustdoc) - #161880 (fix rustc_lint_defs doctest issues) - #161883 (better deal with internal features being injected into doctests) - #161887 (std: uefi: fix File::seek returning the EOF sentinel) - #161897 (Reject contract attributes without arguments) - #161909 (Report the configured Polonius default in -Z help) - #161910 (Add rustdoc-html regression test for generated macro) - #161914 (Retroactively add relnotes for `bool::{ok_or,ok_or_else}` (1.98.0)) - #161924 (Windows: document that `normalize_lexically` converts `/` to `\`) - #161927 (Change `rustc_middle/src/hooks/mod.rs` to `hooks.rs`)

Rollup of 17 pull requests Successful merges: - #161945 (std: optimise IO error formatting) - #160594 (attach global target features to module-level assembly) - #161577 (implement [u8]::split_ascii_whitespace) - #161858 (fix ICE in generic_const_parameter_types with inherents) - #161377 ([bootstrap] Don't reverse the order of dylib search path entries) - #161804 (Document PartialOrd behavior for Option<T> where T: PartialOrd) - #161865 (loongarch: support passing `u128`/`i128` to inline assembly) - #161877 (Do not load macro metadata for local definitions in rustdoc) - #161880 (fix rustc_lint_defs doctest issues) - #161883 (better deal with internal features being injected into doctests) - #161887 (std: uefi: fix File::seek returning the EOF sentinel) - #161888 (compiler: Allow safestack to be togglable via #[sanitize(safestack = "...")]) - #161897 (Reject contract attributes without arguments) - #161910 (Add rustdoc-html regression test for generated macro) - #161914 (Retroactively add relnotes for `bool::{ok_or,ok_or_else}` (1.98.0)) - #161924 (Windows: document that `normalize_lexically` converts `/` to `\`) - #161927 (Change `rustc_middle/src/hooks/mod.rs` to `hooks.rs`)

@Kobzol

Rollup merge of #161377 - jnkel:fix-dylib-search-order, r=jieyouxu [bootstrap] Don't reverse the order of dylib search path entries The `add_dylib_path` helper function prepends paths to the beginning of the dynamic linker search path, but it reverses their order while doing so. This is surprising and undocumented, and seems to be unexpected by several callers of this function. Particularly, [`rustc_lib_paths`](https://github.com/rust-lang/rust/blob/f7d782a3be46d6bb4b9792fe69a61db389ba1769/src/bootstrap/src/core/builder/mod.rs#L1375) appends the `ci-llvm` path to the list it returns; reversing the order puts `ci-llvm` at a higher priority than the compiler's lib directory. On my system, this currently causes `./x test` to fail (when building the unstable book), because the stage0 compiler is run using CI LLVM instead of stage0 LLVM (which are currently different because stage0 is on LLVM 22 while main is on LLVM 23). Might be worth a try build as this change could potentially cause issues if there is somewhere we depend on this ordering reversal. I checked all the call-sites (and ran `./x test` locally) and I don't think anyone *intentionally* relied on the ordering being reversed. I did find one snippet that concerned me (from #144303, cc @Kobzol): https://github.com/rust-lang/rust/blob/f7d782a3be46d6bb4b9792fe69a61db389ba1769/src/bootstrap/src/core/build_steps/test.rs#L437-L448 The comment states we're inserting `builder.rustc_libdir(tested_compiler)` at the highest priority in the search path, but because `add_dylib_path` reversed the ordering, it's actually inserted at the *lowest* priority. I don't know how to reproduce the issue this was supposed to fix, so I can't be sure that this PR doesn't cause a regression. Follow-up to #161335. r? @jieyouxu

Check to ensure we're running against the correct LLVM version The recent LLVM version bump exposed several cases of mishandling LLVM versions, both in-tree and downstream (rust-lang#161335, rust-lang#161377, rust-lang#161572, rust-lang#162013, https://rust-lang.zulipchat.com/#narrow/channel/122651-general/topic/opt-dist.20pipeline.20failure.20in.20MSYS2.20CI.20when.20compiling.2E.2E.2E/with/619077952). If the compiler is run against an incompatible LLVM version, the most common failure mode is a segfault within LLVM, often when looking up target information. This is not obvious to debug, so this PR adds an LLVM version check before initializing LLVM so that we can produce a clearer error. The second commit in this PR performs a `dladdr` lookup to print the path to the LLVM we're using. We already have code to do this for finding the sysroot, which I repurposed. However, I don't mind reverting this if it's too complex/risky. I would appreciate if someone with permissions could trigger a try build on AIX, Windows, and WASI as the second commit touches platform-specific code that I can't test locally. Before: ``` error: rustc interrupted by SIGSEGV, printing backtrace 0 librustc_driver-18049a207bb38ba8.dy 0x000000010e09e9b8 _RNvNtCsfNrGi27GPxl_17rustc_driver_impl14signal_handler17print_stack_trace + 140 1 libsystem_platform.dylib 0x0000000184c7d744 _sigtramp + 56 2 libLLVM.dylib 0x000000011a9e22e0 _ZNK4llvm15MCSubtargetInfo13checkFeaturesENS_9StringRefE + 40 3 librustc_driver-18049a207bb38ba8.dy 0x000000010e44c798 LLVMRustHasFeature + 104 4 librustc_driver-18049a207bb38ba8.dy 0x000000010e3c4e34 _RINvXs0_NtNtNtCsk8HLZXaYIk4_4core4iter8adapters3mapINtB6_3MapINtNtB8_7flatten7FlatMapINtNtB8_6filter6FilterINtNtNtBc_5slice4iter4IterTReNtNtCs79s86CIooN0_12rustc_target15target_features9StabilityRSB28_EENCINvNtCses5MBT5CPFU_17rustc_codegen_ssa15target_features24internal_target_featuresKj2_NCNvNtCsgXm2bqwPj4W_18rustc_codegen_llvm9llvm_util13target_config0NCB4G_s_0E0EIBO_INtNtNtNtCs99cPMl0y5Ob_3std11collections4hash3set8IntoIterB28_ENCNCB3h_s_00ENCB3h_s_0ENCINvXs8_NtCsdLs5ZkLaCXa_9hashbrown3setINtB7v_7HashSetNtNtCsSGoTcZpb2F_10rustc_span6symbol6SymbolNtCs5ZGGmiYplBm_10rustc_hash13FxBuildHasherEINtNtNtBa_6traits7collect6ExtendB8e_E6extendBX_E0ENtNtB9I_8iterator8Iterator4folduNCINvNvBar_8for_each4callTB8e_uENCINvXs1i_NtB7x_3mapINtBbD_7HashMapB8e_uB8V_EIB9E_Bbm_E6extendBN_E0E0EB4K_ + 880 5 librustc_driver-18049a207bb38ba8.dy 0x000000010e2ad884 _RINvXs1i_NtCsdLs5ZkLaCXa_9hashbrown3mapINtB7_7HashMapNtNtCsSGoTcZpb2F_10rustc_span6symbol6SymboluNtCs5ZGGmiYplBm_10rustc_hash13FxBuildHasherEINtNtNtNtCsk8HLZXaYIk4_4core4iter6traits7collect6ExtendTBP_uEE6extendINtNtNtB2m_8adapters3map3MapINtNtB3r_7flatten7FlatMapINtNtB3r_6filter6FilterINtNtNtB2o_5slice4iter4IterTReNtNtCs79s86CIooN0_12rustc_target15target_features9StabilityRSB52_EENCINvNtCses5MBT5CPFU_17rustc_codegen_ssa15target_features24internal_target_featuresKj2_NCNvNtCsgXm2bqwPj4W_18rustc_codegen_llvm9llvm_util13target_config0NCB7A_s_0E0EIB3n_INtNtNtNtCs99cPMl0y5Ob_3std11collections4hash3set8IntoIterB52_ENCNCB6b_s_00ENCB6b_s_0ENCINvXs8_NtB9_3setINtBaq_7HashSetBP_B1x_EIB2g_BP_E6extendB3O_E0EEB7E_ + 344 6 librustc_driver-18049a207bb38ba8.dy 0x000000010e2b1ec4 _RINvXs8_NtCsdLs5ZkLaCXa_9hashbrown3setINtB6_7HashSetNtNtCsSGoTcZpb2F_10rustc_span6symbol6SymbolNtCs5ZGGmiYplBm_10rustc_hash13FxBuildHasherEINtNtNtNtCsk8HLZXaYIk4_4core4iter6traits7collect6ExtendBO_E6extendINtNtNtB2k_8adapters7flatten7FlatMapINtNtB3m_6filter6FilterINtNtNtB2m_5slice4iter4IterTReNtNtCs79s86CIooN0_12rustc_target15target_features9StabilityRSB4G_EENCINvNtCses5MBT5CPFU_17rustc_codegen_ssa15target_features24internal_target_featuresKj2_NCNvNtCsgXm2bqwPj4W_18rustc_codegen_llvm9llvm_util13target_config0NCB7e_s_0E0EINtNtB3m_3map3MapINtNtNtNtCs99cPMl0y5Ob_3std11collections4hash3set8IntoIterB4G_ENCNCB5P_s_00ENCB5P_s_0EEB7i_ + 68 7 librustc_driver-18049a207bb38ba8.dy 0x000000010e2bfa90 _RINvNtCses5MBT5CPFU_17rustc_codegen_ssa15target_features24internal_target_featuresKj2_NCNvNtCsgXm2bqwPj4W_18rustc_codegen_llvm9llvm_util13target_config0NCB1o_s_0EB1s_ + 148 8 librustc_driver-18049a207bb38ba8.dy 0x000000010e2fb918 _RNvNtCsgXm2bqwPj4W_18rustc_codegen_llvm9llvm_util13target_config + 68 9 librustc_driver-18049a207bb38ba8.dy 0x000000010e292fb0 _RNvNtCs6x0lOIkloew_15rustc_interface4util17add_configuration + 48 10 librustc_driver-18049a207bb38ba8.dy 0x000000010e06b204 _RINvMs_Csfkr8sXZt4uY_10scoped_tlsINtB5_9ScopedKeyNtCsSGoTcZpb2F_10rustc_span14SessionGlobalsE3setNCNCNCINvNtCs6x0lOIkloew_15rustc_interface4util26run_in_thread_with_globalsNCINvB1G_31run_in_thread_pool_with_globalsNCINvNtB1I_9interface12run_compileruNCNvCsfNrGi27GPxl_17rustc_driver_impl12run_compiler0Es0_0uE0uE000uEB44_ + 1112 11 librustc_driver-18049a207bb38ba8.dy 0x000000010e090914 _RINvCsSGoTcZpb2F_10rustc_span27create_session_globals_thenuNCNCNCINvNtCs6x0lOIkloew_15rustc_interface4util26run_in_thread_with_globalsNCINvB14_31run_in_thread_pool_with_globalsNCINvNtB16_9interface12run_compileruNCNvCsfNrGi27GPxl_17rustc_driver_impl12run_compiler0Es0_0uE0uE000EB3s_ + 168 12 librustc_driver-18049a207bb38ba8.dy 0x000000010e07823c _RINvNtNtCs99cPMl0y5Ob_3std3sys9backtrace28___rust_begin_short_backtraceNCNCINvNtCs6x0lOIkloew_15rustc_interface4util26run_in_thread_with_globalsNCINvB1e_31run_in_thread_pool_with_globalsNCINvNtB1g_9interface12run_compileruNCNvCsfNrGi27GPxl_17rustc_driver_impl12run_compiler0Es0_0uE0uE00uEB3C_ + 112 13 librustc_driver-18049a207bb38ba8.dy 0x000000010e04efa4 _RNSNvYNCINvNtNtCs99cPMl0y5Ob_3std6thread9lifecycle15spawn_uncheckedNCNCINvNtCs6x0lOIkloew_15rustc_interface4util26run_in_thread_with_globalsNCINvB1a_31run_in_thread_pool_with_globalsNCINvNtB1c_9interface12run_compileruNCNvCsfNrGi27GPxl_17rustc_driver_impl12run_compiler0Es0_0uE0uE00uEs_0INtNtNtCsk8HLZXaYIk4_4core3ops8function6FnOnceuE9call_once6vtableB3y_ + 208 14 librustc_driver-18049a207bb38ba8.dy 0x0000000111697118 _RNvNvMs0_NtNtNtCs99cPMl0y5Ob_3std3sys6thread4unixNtB7_6Thread3new12thread_start + 392 15 libsystem_pthread.dylib 0x0000000184c73c58 _pthread_start + 136 16 libsystem_pthread.dylib 0x0000000184c6ec1c thread_start + 8 note: we would appreciate a report at https://github.com/rust-lang/rust help: you can increase rustc's stack size by setting RUST_MIN_STACK=33554432 ``` After: ``` thread 'rustc' (3568488) panicked at compiler/rustc_codegen_llvm/src/llvm_util.rs:59:13: LLVM version mismatch: this compiler was built for LLVM 23, but LLVM 22.1.8 was found at /Users/keljonathan/code/rust/build/aarch64-apple-darwin/stage0/lib/libLLVM.dylib stack backtrace: 0: __rustc::rust_begin_unwind at /rustc/08d5b675a9b2abdca5e2fe4eabe0e07bbda15d49/library/std/src/panicking.rs:679:5 1: core::panicking::panic_fmt at /rustc/08d5b675a9b2abdca5e2fe4eabe0e07bbda15d49/library/core/src/panicking.rs:80:14 2: configure_llvm at ./compiler/rustc_codegen_llvm/src/llvm_util.rs:59:13 3: {closure#0} at ./compiler/rustc_codegen_llvm/src/llvm_util.rs:35:13 4: {closure#0}<rustc_codegen_llvm::llvm_util::init::{closure_env#0}> at /rustc/08d5b675a9b2abdca5e2fe4eabe0e07bbda15d49/library/std/src/sync/once.rs:166:41 5: <std::sys::sync::once::queue::Once>::call at /rustc/08d5b675a9b2abdca5e2fe4eabe0e07bbda15d49/library/std/src/sys/sync/once/queue.rs:225:21 6: call_once<rustc_codegen_llvm::llvm_util::init::{closure_env#0}> at /rustc/08d5b675a9b2abdca5e2fe4eabe0e07bbda15d49/library/std/src/sync/once.rs:166:20 7: init at ./compiler/rustc_codegen_llvm/src/llvm_util.rs:34:14 8: init at ./compiler/rustc_codegen_llvm/src/lib.rs:223:9 9: {closure#2}<(), rustc_driver_impl::run_compiler::{closure_env#0}> at ./compiler/rustc_interface/src/interface.rs:440:29 10: {closure#0}<rustc_interface::interface::run_compiler::{closure_env#2}<(), rustc_driver_impl::run_compiler::{closure_env#0}>, ()> at ./compiler/rustc_interface/src/util.rs:223:17 11: {closure#0}<rustc_interface::util::run_in_thread_pool_with_globals::{closure_env#0}<rustc_interface::interface::run_compiler::{closure_env#2}<(), rustc_driver_impl::run_compiler::{closure_env#0}>, ()>, ()> at ./compiler/rustc_interface/src/util.rs:180:24 12: set<rustc_span::SessionGlobals, rustc_interface::util::run_in_thread_with_globals::{closure#0}::{closure#0}::{closure_env#0}<rustc_interface::util::run_in_thread_pool_with_globals::{closure_env#0}<rustc_interface::interface::run_compiler::{closure_env#2}<(), rustc_driver_impl::run_compiler::{closure_env#0}>, ()>, ()>, ()> at /Users/keljonathan/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/scoped-tls-1.0.1/src/lib.rs:137:9 13: create_session_globals_then<(), rustc_interface::util::run_in_thread_with_globals::{closure#0}::{closure#0}::{closure_env#0}<rustc_interface::util::run_in_thread_pool_with_globals::{closure_env#0}<rustc_interface::interface::run_compiler::{closure_env#2}<(), rustc_driver_impl::run_compiler::{closure_env#0}>, ()>, ()>> at ./compiler/rustc_span/src/lib.rs:156:21 14: {closure#0}<rustc_interface::util::run_in_thread_pool_with_globals::{closure_env#0}<rustc_interface::interface::run_compiler::{closure_env#2}<(), rustc_driver_impl::run_compiler::{closure_env#0}>, ()>, ()> at ./compiler/rustc_interface/src/util.rs:176:17 note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace. error: the compiler unexpectedly panicked. This is a bug note: we would appreciate a bug report: https://github.com/rust-lang/rust/issues/new?labels=C-bug%2C+I-ICE%2C+T-compiler&template=ice.md note: please make sure that you have updated to the latest nightly note: please attach the file at `/Users/keljonathan/code/rust/rustc-ice-2026-08-25T22_23_11-1423.txt` to your bug report note: rustc 1.100.0-dev running on aarch64-apple-darwin note: compiler flags: -C rpath -C debuginfo=0 -Z unstable-options query stack during panic: end of query stack ```

rustbot added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Aug 19, 2026

rustbot assigned jieyouxu Aug 19, 2026

rustbot added the T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) label Aug 19, 2026

This comment has been minimized.

Sign in to view

[bootstrap] Don't reverse the order of dylib search path entries

67e8a19

jnkel force-pushed the fix-dylib-search-order branch from 02b6017 to 67e8a19 Compare August 19, 2026 23:44

jieyouxu reviewed Aug 20, 2026

View reviewed changes

Comment thread src/bootstrap/src/utils/helpers.rs

jnkel mentioned this pull request Aug 25, 2026

Check to ensure we're running against the correct LLVM version #161788

Open

jieyouxu approved these changes Aug 28, 2026

View reviewed changes

rust-bors Bot added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Aug 28, 2026

JonathanBrouwer mentioned this pull request Aug 28, 2026

Rollup of 12 pull requests #161934

Closed

JonathanBrouwer mentioned this pull request Aug 28, 2026

Rollup of 11 pull requests #161939

Closed

JonathanBrouwer mentioned this pull request Aug 28, 2026

Rollup of 15 pull requests #161942

Closed

JonathanBrouwer mentioned this pull request Aug 28, 2026

Rollup of 16 pull requests #161949

Closed

JonathanBrouwer mentioned this pull request Aug 28, 2026

Rollup of 16 pull requests #161952

Closed

Zalathar mentioned this pull request Aug 29, 2026

Rollup of 17 pull requests #161955

Closed

jhpratt mentioned this pull request Aug 29, 2026

Rollup of 17 pull requests #161959

Merged

rust-bors Bot merged commit 80040c6 into rust-lang:main Aug 29, 2026
13 checks passed

rustbot added this to the 1.100.0 milestone Aug 29, 2026

Navigation Menu

Uh oh!

Uh oh!

[bootstrap] Don't reverse the order of dylib search path entries - #161377

[bootstrap] Don't reverse the order of dylib search path entries#161377
rust-bors[bot] merged 1 commit into
rust-lang:mainfrom
jnkel:fix-dylib-search-order

jnkel commented Aug 19, 2026 •

edited by rustbot

Loading

Uh oh!

This comment has been minimized.

Uh oh!

Kobzol commented Aug 20, 2026

Uh oh!

jieyouxu commented Aug 25, 2026

Uh oh!

jieyouxu left a comment •

edited by rustbot

Loading

Uh oh!

rust-bors Bot commented Aug 28, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

	// The `cargo` command configured above has dylib dir path set to the `build_compiler`'s
	// libdir. That causes issues in cargo test, because the programs that cargo compiles are
	// incorrectly picking that libdir, even though they should be picking the
	// `tested_compiler`'s libdir. We thus have to override the precedence here.
	let mut existing_dylib_paths = cargo
	.get_envs()
	.find(\|(k, _)\| *k == OsStr::new(dylib_path_var()))
	.and_then(\|(_, v)\| v)
	.map(\|value\| split_paths(value).collect::<Vec<PathBuf>>())
	.unwrap_or_default();
	existing_dylib_paths.insert(0, builder.rustc_libdir(tested_compiler));
	add_dylib_path(existing_dylib_paths, &mut cargo);

Uh oh!

Uh oh!

Conversation

jnkel commented Aug 19, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

This comment has been minimized.

Uh oh!

Kobzol commented Aug 20, 2026

Uh oh!

jieyouxu commented Aug 25, 2026

Uh oh!

jieyouxu left a comment • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rust-bors Bot commented Aug 28, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

jnkel commented Aug 19, 2026 •

edited by rustbot

Loading

jieyouxu left a comment •

edited by rustbot

Loading