tools cannot find `-lLLVM` in a non-standard link path

[cuviper]

In my build of Rust 1.41 on EPEL7, I see link failures first for clippy and rls, which are allowed by rustbuild, and then a hard failure on rustdoc.

   Compiling rustdoc-tool v0.0.0 (/builddir/build/BUILD/rustc-1.41.0-src/src/tools/rustdoc)
error: linking with `cc` failed: exit code: 1
  |
  = note: "cc" "-Wl,--as-needed" [...] "-L" "/builddir/build/BUILD/rustc-1.41.0-src/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/lib" "-Wl,-Bdynamic" "-lrustc_driver-8eceda5ae2b7dbad" [...] "-lLLVM-7" [...]
  = note: /usr/bin/ld: cannot find -lLLVM-7
          collect2: error: ld returned 1 exit status

This seems to be a recurrence of #40717 (comment), where the -l link library for LLVM is passed on to dependent crates, but the -L library path is not, so it fails to actually link the tools.

I called out librustc_driver in the excerpted link line above, because in a normal build with dynamic LLVM, that's the only thing that actually uses LLVM symbols. The rustdoc binary does not usually end up with a direct dependency on LLVM, so it doesn't really need that -lLLVM at all.

The problem in #40717 went away once we started loading codegen dynamically in #47671. However, #67077 started linking LLVM directly again, and this just reached stable 1.41.

My former workaround of setting LIBRARY_PATH=$(llvm-config --libdir) still works. This is specifically the compile-time link path, not the runtime LD_LIBRARY_PATH. Maybe we could kludge that into rustbuild somehow?

[Mark-Simulacrum]

I would not be personally opposed to including LLVM's libdir during compile time, so long as that's not visible in our final artifacts (which I think is true?).

[shogun46]

Thank you @cuviper for the workaround, I'm able to compile Rust 1.41 now. Just another suggestion for improvement:

after adding export LIBRARY_PATH=$(llvm-config --libdir):$LIBRARY_PATH my build was still failing as the variable was initially empty and it ended up with a trailing :, which messed up the compilation. After removing the unneeded : it worked as expected.

Maybe a "sanity-check" could be implemented when parsing environment variables so these kind of errors could be mitigated?

[cuviper]

I don't think anything in Rust parses LIBRARY_PATH right now, just the linker itself.

[cuviper]

I just discovered the giant comment in commit 8b9c539, which is describing nearly the same issue. Perhaps better propagation of the library path will help improve that too.