Change:
let target_libs = find_files(&target_libs, &lib_path); // Copy runtime dlls next to rustc.exe <del> let dist_bin_dir = rust_root.join("bin/"); fs::create_dir_all(&dist_bin_dir).expect("creating dist_bin_dir failed"); for src in rustc_dlls { builder.copy_link_to_folder(&src, &dist_bin_dir); </del> <ins> let rust_bin_dir = rust_root.join("bin/"); fs::create_dir_all(&rust_bin_dir).expect("creating rust_bin_dir failed"); for src in &rustc_dlls { builder.copy_link_to_folder(src, &rust_bin_dir); } if builder.config.lld_enabled { // rust-lld.exe also needs runtime dlls let rust_target_bin_dir = rust_root.join("lib/rustlib").join(target).join("bin"); fs::create_dir_all(&rust_target_bin_dir).expect("creating rust_target_bin_dir failed"); for src in &rustc_dlls { builder.copy_link_to_folder(src, &rust_target_bin_dir); } </ins> } //Copy platform tools to platform-specific bin directory <del> let target_bin_dir = plat_root.join("lib").join("rustlib").join(target).join("bin").join("self-contained"); fs::create_dir_all(&target_bin_dir).expect("creating target_bin_dir failed"); </del> <ins> let plat_target_bin_self_contained_dir = plat_root.join("lib/rustlib").join(target).join("bin/self-contained"); fs::create_dir_all(&plat_target_bin_self_contained_dir) .expect("creating plat_target_bin_self_contained_dir failed"); </ins> for src in target_tools { <del> builder.copy_link_to_folder(&src, &target_bin_dir); </del> <ins> builder.copy_link_to_folder(&src, &plat_target_bin_self_contained_dir); </ins> } // Warn windows-gnu users that the bundled GCC cannot compile C files builder.create( <del> &target_bin_dir.join("GCC-WARNING.txt"), </del> <ins> &plat_target_bin_self_contained_dir.join("GCC-WARNING.txt"), </ins> "gcc.exe contained in this folder cannot be used for compiling C files - it is only  used as a linker. In order to be able to compile projects containing C code use  the GCC provided by MinGW or Cygwin.", ); //Copy platform libs to platform-specific lib directory <del> let target_lib_dir = plat_root.join("lib").join("rustlib").join(target).join("lib").join("self-contained"); fs::create_dir_all(&target_lib_dir).expect("creating target_lib_dir failed"); </del> <ins> let plat_target_lib_self_contained_dir = plat_root.join("lib/rustlib").join(target).join("lib/self-contained"); fs::create_dir_all(&plat_target_lib_self_contained_dir) .expect("creating plat_target_lib_self_contained_dir failed"); </ins> for src in target_libs { <del> builder.copy_link_to_folder(&src, &target_lib_dir); </del> <ins> builder.copy_link_to_folder(&src, &plat_target_lib_self_contained_dir); </ins> } }

Discussion:
Failed reason is can't find 'libgccsseh-1.dll' and 'libwinpthread-1.dll' when fallback to 1.77.2 or using 'x86_64-pc-windows-msvc' host tool then every thing is ok
Those libraries are provided alongside other Rust binaries: Note is located inside rustlib: I rust-lld should be called with PATH set to , or at least used to be. Do you have an example that reproduces the problem? Hopefully, we can bisect it to easily find the problem.
I have tested using clean rust host toolchain installed by rustinit, and just build , then it reproduce the problem. note: in need change '' and '' before build, because they have '{{' and '}}'
searched nightlies: from nightly-2024-02-01 to nightly-2024-03-16 regressed nightly: nightly-2024-02-22 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.8</summaryHost triple: x86_64-pc-windows-gnu Reproduce with: </detailsWon't be as easy to debug as I hoped. do you have any idea which change could case it? EDIT: perhaps No idea how to test it without CI builds though.
If I understand correctly, when is in on Windows, it makes no difference. What the removed code path did was adding that to . In , was changed to false by default (), so probably the rustup change is related. is it possible for you to add and check it again? I don't have a Windows machine available at hand :( Also, could you check if rustc appends host tool bin to ? It but I am not particularly sure.
Would you mind sharing the output of that shows the version of rustup you are using,
Thought it might be important to add; all my tests were made with only present in PATH: Yes, but apparently it's not in when tools from are called. works fine so that sort of confirms it. Adding that env makes no difference: I can do some builds during the weekend. Judging from that code, it only adds .
My fault. Should be not .
Oh, I had missed that too works fine.

I set RUSTUPWINDOWSPATHADDBIN=1 then build works fine too
do you have any thought on this? Should we revert should rustc do something else instead? I don't know how msvc works but gnu doesn't.
Another option would be to add it to the end of . So it has the lowest precedence but any necessary DLLs it provides can still be found.
I guess msvc works because it's required dlls has been installed by Windows OS or MSVC build tool
are you talking about a fix in cargo or rustc? What happens if we invoke rustc directly to cross-compile? If it doesn't work either, I feel like this should be addressed on rustc or linker invocation side.
Runtime libraries are located alongside rustc, so invoking it directly would work fine. The same cannot be said about bins inside , but is it even supported to invoke them manually?
This would be my inclination that rustc ensures that it has the PATH set up correctly. We just need to make sure that things like and don't regress again. I suspect adding the directory to PATH will make proc-macros fail recursive calls to rustc or cargo via rustup. I'm not sure how much we should care about that. The only solution I can think there is to separate the DLLs into a separate directory.
I'm solving this now in my PR by shipping the required runtime DLLs along with too. It must be possible to run without relying on any variable being set. We already ship these runtime DLLs alongside , so doing the same for feels like a reasonable thing to do. This solution won't require or any other modification to the environment variable.