rustdoc-tool does not build with --enable-llvm-link-shared

[whitequark]

Seems to be missing a -L flag:

  = note: /usr/bin/ld: cannot find -lLLVMX86Disassembler
          /usr/bin/ld: cannot find -lLLVMX86AsmParser
          /usr/bin/ld: cannot find -lLLVMX86CodeGen
...

Any ideas on fixing this?

[whitequark]

Horrible hacky workaround:

diff --git a/src/Cargo.lock b/src/Cargo.lock
index bc1fdf40b0..e5024f0427 100644
--- a/src/Cargo.lock
+++ b/src/Cargo.lock
@@ -1858,6 +1858,7 @@ dependencies = [
 name = "rustdoc-tool"
 version = "0.0.0"
 dependencies = [
+ "rustc_llvm 0.0.0",
  "rustdoc 0.0.0",
 ]
 
diff --git a/src/bootstrap/tool.rs b/src/bootstrap/tool.rs
index a05e58e6a2..e169e8bf12 100644
--- a/src/bootstrap/tool.rs
+++ b/src/bootstrap/tool.rs
@@ -313,6 +313,10 @@ impl Step for Rustdoc {
         cargo.env("RUSTC_DEBUGINFO", builder.config.rust_debuginfo.to_string())
              .env("RUSTC_DEBUGINFO_LINES", builder.config.rust_debuginfo_lines.to_string());
 
+        if build.config.llvm_link_shared {
+            cargo.env("LLVM_LINK_SHARED", "1");
+        }
+
         build.run(&mut cargo);
         // Cargo adds a number of paths to the dylib search path on windows, which results in
         // the wrong rustdoc being executed. To avoid the conflicting rustdocs, we name the "tool"
diff --git a/src/tools/rustdoc/Cargo.toml b/src/tools/rustdoc/Cargo.toml
index 344f617ef9..110f01b1bc 100644
--- a/src/tools/rustdoc/Cargo.toml
+++ b/src/tools/rustdoc/Cargo.toml
@@ -12,3 +12,4 @@ path = "main.rs"
 
 [dependencies]
 rustdoc = { path = "../../librustdoc" }
+rustc_llvm = { path = "../../librustc_llvm" }
diff --git a/src/tools/rustdoc/main.rs b/src/tools/rustdoc/main.rs
index 9c37e249ba..fd37235722 100644
--- a/src/tools/rustdoc/main.rs
+++ b/src/tools/rustdoc/main.rs
@@ -9,5 +9,6 @@
 // except according to those terms.
 
 extern crate rustdoc;
+extern crate rustc_llvm;
 
 fn main() { rustdoc::main() }

[eddyb]

Huh, it should be getting it through rustdoc -> rustc_driver -> rustc_trans -> rustc_llvm.

cc @alexcrichton

[alexcrichton]

The link paths aren't propagated because rustdoc is in a separate Cargo project, we'll need to manually insert necessary link paths via a build script in rustdoc.

[eddyb]

@alexcrichton Ah, so none of the information is in the Rust rlib / dylib metadata?

[alexcrichton]

Correct yeah, link paths aren't stored in metadata, only libraries linked.

[whitequark]

Related: LLVM_CONFIG should be properly set for rustdoc build, too, or the wrong llvm-config (from PATH) would be used:

Building rustdoc for stage2 (x86_64-unknown-linux-gnu)
   Compiling rustc_llvm v0.0.0 (file:///home/maglab/artiq-dev/artiq_3.1/rust/src/librustc_llvm)
error: failed to run custom build command for `rustc_llvm v0.0.0 (file:///home/maglab/artiq-dev/artiq_3.1/rust/src/librustc_llvm)`
process didn't exit successfully: `/home/maglab/artiq-dev/artiq_3.1/rust/build/build/x86_64-unknown-linux-gnu/stage2-tools/release/build/rustc_llvm-5f6e96f94cb8b094/build-script-build` (exit code: 1)
--- stdout
cargo:rerun-if-changed=llvm-config
cargo:rerun-if-env-changed=LLVM_CONFIG


**failed to execute command: "llvm-config" "--version"**
error: No such file or directory (os error 2)

This is not currently handled by my workaround above, though.

[whitequark]

The following takes care of it:

diff --git a/src/bootstrap/tool.rs b/src/bootstrap/tool.rs
index e95a5e0743..5cea0ad1fc 100644
--- a/src/bootstrap/tool.rs
+++ b/src/bootstrap/tool.rs
@@ -313,6 +313,8 @@ impl Step for Rustdoc {
         cargo.env("RUSTC_DEBUGINFO", builder.config.rust_debuginfo.to_string())
              .env("RUSTC_DEBUGINFO_LINES", builder.config.rust_debuginfo_lines.to_string());

+        cargo.env("LLVM_CONFIG", builder.llvm_config(target));
+
         build.run(&mut cargo);
         // Cargo adds a number of paths to the dylib search path on windows, which results in
         // the wrong rustdoc being executed. To avoid the conflicting rustdocs, we name the "tool"

[o01eg]

It also affects compilation with system LLVM.

[whitequark]

Any guidance on how to properly fix this upstream?

[steveklabnik]

Triage: not aware of any fixes here