2 files changed, 63 insertions, 0 deletions
diff --git a/lang/rust/files/no-hardlinks/patch-src_bootstrap_lib.rs b/lang/rust/files/no-hardlinks/patch-src_bootstrap_lib.rs
new file mode 100644
index 000000000000..081c2056ad2c
--- /dev/null
+++ b/lang/rust/files/no-hardlinks/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/no-hardlinks/patch-src_bootstrap_native.rs b/lang/rust/files/no-hardlinks/patch-src_bootstrap_native.rs
new file mode 100644
index 000000000000..18a334c6b76c
--- /dev/null
+++ b/lang/rust/files/no-hardlinks/patch-src_bootstrap_native.rs
@@ -0,0 +1,35 @@
+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-08-24 15:00:49 UTC
++++ src/bootstrap/native.rs
+@@ -517,26 +522,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