diff options
Diffstat (limited to 'lang/rust/files')
| -rw-r--r-- | lang/rust/files/patch-src_bootstrap_lib.rs | 28 | ||||
| -rw-r--r-- | lang/rust/files/patch-src_bootstrap_native.rs | 34 |
2 files changed, 28 insertions, 34 deletions
diff --git a/lang/rust/files/patch-src_bootstrap_lib.rs b/lang/rust/files/patch-src_bootstrap_lib.rs new file mode 100644 index 000000000000..081c2056ad2c --- /dev/null +++ b/lang/rust/files/patch-src_bootstrap_lib.rs @@ -0,0 +1,28 @@ +Attempt to fix intermittent "can't find crate for `std`" build failures + +The location of rustc (found via env::current_exe()) is used to +find the right libstd. However it might have been "copied" by +creating a hard link to the new location instead. Like /proc/curproc/file, +KERN_PROC_PATHNAME (used internally by current_exe()) can return +any of the file's multiple paths. Most of the time it returns the +right rustc path and the build will succeed but occasionally it +will return the "wrong" path and the build fails with: + + error[E0463]: can't find crate for `std` + +If this is right a viable workaround should be to never create hard +links during the build, so let's try that. + +--- src/bootstrap/lib.rs.orig 2020-07-23 20:16:43 UTC ++++ src/bootstrap/lib.rs +@@ -1173,10 +1173,6 @@ impl Build { + if metadata.file_type().is_symlink() { + let link = t!(fs::read_link(src)); + t!(symlink_file(link, dst)); +- } else if let Ok(()) = fs::hard_link(src, dst) { +- // Attempt to "easy copy" by creating a hard link +- // (symlinks don't work on windows), but if that fails +- // just fall back to a slow `copy` operation. + } else { + if let Err(e) = fs::copy(src, dst) { + panic!("failed to copy `{}` to `{}`: {}", src.display(), dst.display(), e) diff --git a/lang/rust/files/patch-src_bootstrap_native.rs b/lang/rust/files/patch-src_bootstrap_native.rs deleted file mode 100644 index 7af832a912d3..000000000000 --- a/lang/rust/files/patch-src_bootstrap_native.rs +++ /dev/null @@ -1,34 +0,0 @@ -There seems to be some kind of race when using llvm-config-wrapper -for building rust-lld. Attempt to improve reliability of the build -by not using it. llvm-config-wrapper is a hack in the first place -that is only really needed on Windows. - ---- src/bootstrap/native.rs.orig 2020-05-03 19:47:59 UTC -+++ src/bootstrap/native.rs -@@ -488,25 +488,9 @@ impl Step for Lld { - let mut cfg = cmake::Config::new(builder.src.join("src/llvm-project/lld")); - configure_cmake(builder, target, &mut cfg, true); - -- // This is an awful, awful hack. Discovered when we migrated to using -- // clang-cl to compile LLVM/LLD it turns out that LLD, when built out of -- // tree, will execute `llvm-config --cmakedir` and then tell CMake about -- // that directory for later processing. Unfortunately if this path has -- // forward slashes in it (which it basically always does on Windows) -- // then CMake will hit a syntax error later on as... something isn't -- // escaped it seems? -- // -- // Instead of attempting to fix this problem in upstream CMake and/or -- // LLVM/LLD we just hack around it here. This thin wrapper will take the -- // output from llvm-config and replace all instances of `\` with `/` to -- // ensure we don't hit the same bugs with escaping. It means that you -- // can't build on a system where your paths require `\` on Windows, but -- // there's probably a lot of reasons you can't do that other than this. -- let llvm_config_shim = env::current_exe().unwrap().with_file_name("llvm-config-wrapper"); - cfg.out_dir(&out_dir) - .profile("Release") -- .env("LLVM_CONFIG_REAL", &llvm_config) -- .define("LLVM_CONFIG_PATH", llvm_config_shim) -+ .define("LLVM_CONFIG_PATH", &llvm_config) - .define("LLVM_INCLUDE_TESTS", "OFF"); - - // While we're using this horrible workaround to shim the execution of |