lang/rust: Attempt to address unreliable rust-lld build

It sometimes fails [0,1] and sometimes succeeds [2,3].  When it
fails it fails with

running: "cmake" "/wrkdirs/usr/ports/lang/rust/work/rustc-1.41.1-src/src/llvm-project/lld" "-DCMAKE_INSTALL_MESSAGE=LAZY" "-DCMAKE_C_COMPILER=cc" "-DCMAKE_CXX_COMPILER=c++" "-DCMAKE_C_FLAGS=-ffunction-sections -fdata-sections -fPIC -m64 -pipe -fstack-protector-strong -fno-strict-aliasing" "-DCMAKE_CXX_FLAGS=-ffunction-sections -fdata-sections -fPIC -m64 -pipe -fstack-protector-strong -fno-strict-aliasing" "-DLLVM_CONFIG_PATH=/wrkdirs/usr/ports/lang/rust/work/rustc-1.41.1-src/build/bootstrap/debug/deps/llvm-config-wrapper" "-DLLVM_INCLUDE_TESTS=OFF" "-DCMAKE_INSTALL_PREFIX=/wrkdirs/usr/ports/lang/rust/work/rustc-1.41.1-src/build/x86_64-unknown-freebsd/lld" "-DCMAKE_BUILD_TYPE=Release"
-- The C compiler identification is Clang 9.0.1
-- The CXX compiler identification is Clang 9.0.1
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
CMake Error at CMakeLists.txt:23 (message):
  llvm-config failed with status No such file or directory

-- Configuring incomplete, errors occurred!

There seems to be some kind of race when using llvm-config-wrapper,
but at the point where LLD is built, both llvm-config and
llvm-config-wrapper should definitely be available.  Both are built
successfully much earlier in the build.  Attempt to improve reliability
by not using the wrapper.  It is a hack in the first place that is
only really needed on Windows.

This is a shot in the dark.  I am unable to reproduce this myself.

[0] http://beefy18.nyi.freebsd.org/data/head-amd64-default/p527397_s358451/logs/errors/rust-1.41.1.log
[1] http://gohan03.nyi.freebsd.org/data/head-amd64-default-baseline/p527486_s358478/logs/errors/rust-1.41.1.log
[2] http://beefy18.nyi.freebsd.org/data/head-amd64-default/p527397_s358451/logs/rust-nightly-1.43.0.20200228.log
[3] http://gohan03.nyi.freebsd.org/data/head-amd64-default-baseline/p527313_s358414/logs/rust-1.41.1.log
This commit is contained in:
Tobias Kortkamp 2020-03-01 11:09:44 +00:00
parent 73ad2248fe
commit d0c2a2ceea
Notes: svn2git 2021-03-31 03:12:20 +00:00
svn path=/head/; revision=527545
2 changed files with 70 additions and 0 deletions

View file

@ -0,0 +1,34 @@
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-02-27 18:39:49 UTC
+++ src/bootstrap/native.rs
@@ -467,25 +467,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");
cfg.build();

View file

@ -0,0 +1,36 @@
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-03-01 09:54:42 UTC
+++ src/bootstrap/native.rs
@@ -472,27 +472,9 @@ impl Step for Lld {
let mut cfg = cmake::Config::new(builder.src.join("src/llvm-project/lld"));
configure_cmake(builder, target, &mut cfg);
- // 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");
cfg.build();