Enable link-shared for LLVM on non-Windows targets

[Mark-Simulacrum]

Even when LLVM is not generally participating in a shared link with rustc, we
will likely still link to the shared dylib from rust-lld, so we still need to
promote it.

Hopefully fixes #76698.

[Mark-Simulacrum]

@bors try

This has a second commit which enables macOS and Windows try builders so that we can hopefully make sure that things work without waiting for a full local build.

[bors]

⌛ Trying commit 1ffb3c170e223980509ec8c8a7ec734e8c4ddf10 with merge 2d7e7d3397bb4d7fda21c806662de7a714cdc4c1...

[rust-log-analyzer]

The job dist-x86_64-msvc of your PR failed (pretty log, raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.

Could not determine the LLVM submodule commit hash. Assuming that an LLVM rebuild is not necessary.
To force LLVM to rebuild, remove the file `D:\a\rust\rust\build\x86_64-pc-windows-msvc\llvm\llvm-finished-building`
llvm-config: error: component libraries and shared library

llvm-config: error: missing: D:\a\rust\rust\build\x86_64-pc-windows-msvc\llvm\build\lib\gtest.lib
llvm-config: error: missing: D:\a\rust\rust\build\x86_64-pc-windows-msvc\llvm\build\lib\gtest_main.lib
llvm-config: error: missing: D:\a\rust\rust\build\x86_64-pc-windows-msvc\llvm\build\lib\LLVMTestingSupport.lib
thread 'main' panicked at 'command did not execute successfully: "D:\\a\\rust\\rust\\build\\x86_64-pc-windows-msvc\\llvm\\build\\bin\\llvm-config.exe" "--libfiles"
expected success, got: exit code: 1', src\build_helper\lib.rs:139:9
failed to run: D:\a\rust\rust\build\bootstrap\debug\bootstrap dist
Build completed unsuccessfully in 0:16:12
== clock drift check ==
  local time: Mon Sep 14 13:59:28 CUT 2020
  local time: Mon Sep 14 13:59:28 CUT 2020
  network time: Mon, 14 Sep 2020 13:59:28 GMT
== end clock drift check ==
##[error]Process completed with exit code 1.
Terminate orphan process: pid (5908) (python)
Terminate orphan process: pid (7528) (sccache)

I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact @rust-lang/infra. (Feature Requests)

[bors]

💔 Test failed - checks-actions

[Mark-Simulacrum]

@bors try

[bors]

⌛ Trying commit a6394d2b8167631e8bff8946da6c2b64bdb34383 with merge 8a552637288ac264194163f7294832fbd89f7836...

[alexcrichton]

Hm I may be a bit confused. IIRC there is weirdness of how the dynamic library is named on macos compared to other platforms, but I think all both Linux and mac are dynamically linked? I thought it was just windows that was static

[Mark-Simulacrum]

We don't set link-shared on macOS, and on linux it's only implicitly set by enabling ThinLTO with LLVM.

It seems like on macOS though the compiler itself isn't linked dynamically to LLVM, as otherwise current nightly wouldn't work, as it lacks any libLLVM.dylib. It seems like the libLLVM.dylib on macOS today is just for rust-lld and other LLVM tools.

[bors]

☀️ Try build successful - checks-actions, checks-azure
Build commit: 8a552637288ac264194163f7294832fbd89f7836 (8a552637288ac264194163f7294832fbd89f7836)

[Mark-Simulacrum]

I have confirmed that on latest nightly RUSTFLAGS=-Clinker=rust-lld cargo run fails on macOS with the "libLLVM.dylib not found" error but does get farther (failing on missing system libraries, but that's because I'm invoking it as rust-lld instead of through a driver like clang, I think) on the toolchain produced by this PR.

[alexcrichton]

Hm ok, I don't really understand what's going on here then. That feels like a bug that macOS is not linked dynamically (but only rust-lld is?), we ideally want all the platforms to be consistent. IIRC the reason Windows doesn't do this is that LLVM's build system doesn't really support generating a shard library (I don't know why though).

Assuming though that this bug is set aside and we try to just fix nightlies, the previous conditional check I believe is correct. The comment makes sense and it I think is what we want, I believe that the bug should probably be fixed elsewehere in the configuration step of rustbuild to ensure that rustbuild doesn't erroneously think that on Windows and macOS LLVM is dynamically linked.

[Mark-Simulacrum]

I don't personally have a Windows machine to test on -- I'd be interested in finding out if/how the llvm tools there work (or not) on current nightly. Judging by their size, they definitely don't include a full LLVM, but we don't ship a libLLVM dll anywhere that I can see. Presumably they work though? Maybe not?

That issue aside (since we should probably fix nightlies before tackling Windows, unless there's a solution covering both)...

It looks like rust-lld (and presumably all the other LLVM tools) are just broken on every target right now except x86_64-unknown-linux-gnu (and Windows, if they ever worked), because that's the only one that enables a shared LLVM in CI I think (and even then, indirectly through enabling LLVM ThinLTO).

We could just try to enabling link-shared on all platforms except for Windows in CI, which presumably would fix this? I'm not sure if that's precisely the right fix. I've pushed up a commit that does so (see the commit message for some explanation as well as this comment).

Interested to hear what you think!

[Mark-Simulacrum]

@bors try

Thought I'd kick off a try build so we can at least see if this is just completely not going to work...

[bors]

⌛ Trying commit 3384b515966f9186cc75952d23305ccf42dd5cc1 with merge 5faa03252d364b6903d28d52397c0a22a5c91f9b...

[bors]

☀️ Try build successful - checks-actions, checks-azure
Build commit: 5faa03252d364b6903d28d52397c0a22a5c91f9b (5faa03252d364b6903d28d52397c0a22a5c91f9b)

[phil-opp]

I don't have a Windows machine either, but for my blog_os project I'm running scheduled CI builds on Linux, Windows, and macOS for each nighly. The build failure seems to happen only on macOS, on Windows is appears to work without problems. Apart from rust-lld, the build process includes llvm-size, llvm-objcopy, and llvm-ar.

[alexcrichton]

I don't personally have a Windows machine to test on -- I'd be interested in finding out if/how the llvm tools there work (or not) on current nightly

FWIW they're statically linked with LLVM, and they work for me at least locally.

We could just try to enabling link-shared on all platforms except for Windows in CI, which presumably would fix this?

I believe this is corret, yeah, and I think ideally we'd just generate an error in rustbuild trying to set link-shared on Windows since I don't think it works at all.

In any case r=me with the tweak to CI config since I think that's what we want to do on macOS anyway

[Mark-Simulacrum]

FWIW they're statically linked with LLVM, and they work for me at least locally.

Hm, interesting. I guess they are quite a bit bigger than on linux targets, so that makes sense. I was sort of expecting ~80 MB each but I guess they're not linking to a good part of LLVM so that's why they're much smaller.

Dropped the try build commits and added a panic! on windows and link-shared configured, so that should be ready to go.

@bors r=alexcrichton rollup=never

This is somewhat likely to bounce I suspect once or twice as we work out any bugs, and in any case is nice to be able to bisect to in case of regressions.

[bors]

📌 Commit f001a0c has been approved by alexcrichton

[alexcrichton]

Ah yeah the tools that bring in codegen libraries are bigger (e.g. llc, opt, lld, etc), but the binary inspection tools benefit from gc in linkers and are pretty small (they don't benefit much from dynamic linking)

[mati865]

I believe this is corret, yeah, and I think ideally we'd just generate an error in rustbuild trying to set link-shared on Windows since I don't think it works at all.

FWIW LLVM does support it in MinGW mode (and it works fine) but we cannot use it since linking to that shared libLLVM.dll would result in hangs because of old mingw-w64 version used on the CI (winpthreads bug).

[bors]

⌛ Testing commit f001a0c with merge 27a45d0...

[bors]

☀️ Test successful - checks-actions, checks-azure
Approved by: alexcrichton
Pushing 27a45d0 to master...