fix: Add rustc dylib directory to compile action search paths

[Arm1stice]

Currently, the library paths for rustc are not included as search paths during compile time. These paths include libLLVM, which are necessary when building crates that use the rustc_private crates

[damienmg]

I don't know if that would be feasible but that would be great to add an examples that would not work without that change. Could you do that or are those too complicated examples?

[Arm1stice]

I made a repo that recreates the bug. The WORKSPACE in the repo contains both the master branch of rules_rust (commented out) and my PR (not commented out) so that you can switch between the two. The current master will fail to build the target :rust_example, but my PR successfully builds. https://github.com/Arm1stice/rules_rust_bug_example

[damienmg]

I think the bug would just repro if you would copy the main.rs and your build file in a subfolder for example, mind doing that so we have a non-regression test along?

[Arm1stice]

Makes sense. I went ahead and created a new example in the examples folder. Because this example requires nightly Rust and the rustc_dev component, I also updated the rust_repository call in the examples WORKSPACE

[damienmg]

Now it fails on buildkite:

  | error[E0463]: can't find crate for `log` which `rustc_driver` depends on
  | --> external/examples/hello_rustc_private/main.rs:3:1
  | \|
  | 3 \| extern crate rustc_driver;
  | \| ^^^^^^^^^^^^^^^^^^^^^^^^^^ can't find crate
  |  
  | error: aborting due to previous error

[Arm1stice]

Looks like, even though external/rust_linux_x86_64/lib is included as a search path in the rustc command for the wasm target, when rustc calls the rust-lld linker, it doesn't include external/rust_linux_x86_64/lib in the linker search paths, causing the linker to fail. This error message is the same that I was getting when attempting to build binaries before, and was the basis for this PR. I wonder why the fix doesn't work for wasm?

[damienmg]

I don't really understand how WASM build works, @mfarrugi do you know?

[mfarrugi]

Not at all :)

…

On Tue, Jun 30, 2020 at 4:44 AM Damien Martin-Guillerez < ***@***.***> wrote: I don't really understand how WASM build works, @mfarrugi <https://github.com/mfarrugi> do you know? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#356 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAROG6CAQ7XFTUMYC7NOEL3RZGQXVANCNFSM4OJX4FJA> .

[Arm1stice]

I'll take another look in the next day or so. I definitely want to figure this out, because I'm currently blocked by the bug this fixes

[Arm1stice]

So if I change the date for the nightly rust to iso_date = "2020-04-21" rather than 2020-06-23, it builds fine. Apparently newer nightlies change something that is making this process break?

EDIT:
2020-04-21 has libLLVM-9-rust-1.44.0-nightly.so while 2020-06-23 has libLLVM-10-rust-1.46.0-nightly.so

2020-05-30 also fails to build and has libLLVM-10-rust-1.45.0-nightly.so

Info so far:
Something happened between the libLLVM-9 and libLLVM-10 change. Current rules_rust master branch can build my example repo above using 2020-04-21 (libLLVM-9) but fails on 1.45 and above nightly builds that use libLLVM-10. Likewise, the WASM example builds fine on 2020-04-21 but fails on newer nightlies. My PR fixes the issue for the new example I added, but the WASM linker is still unable to find the libLLVM-10 dynamic library, even though the folder is included in the search paths passed to rust-lld

[Arm1stice]

This actually might be caused by rust-lang/rust#70838

[Arm1stice]

Closing this PR because it didn't fix the underlying issue. Please see #365 for the actual fix