Skip to content

tools cannot find -lLLVM in a non-standard link path #68714

New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Closed
cuviper opened this issue Jan 31, 2020 · 4 comments · Fixed by #70123
Closed

tools cannot find -lLLVM in a non-standard link path #68714

cuviper opened this issue Jan 31, 2020 · 4 comments · Fixed by #70123

Comments

@cuviper
Copy link
Member

cuviper commented Jan 31, 2020

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
Copy link
Member

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
Copy link

shogun46 commented Mar 7, 2020

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
Copy link
Member Author

cuviper commented Mar 7, 2020

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

@cuviper
Copy link
Member Author

cuviper commented Mar 12, 2020

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.

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants