haskell_repl doesn't work with --remote_download_toplevel

[thufschmitt]

Describe the bug

Running a haskell_repl target with --remote_download_toplevel causes it to crash because it can't find the .so of some dependencies

To Reproduce

# Build it once to populate the remote cache. Everything should work so far
bazel run //tests/multi_repl:c_only_repl --disk_cache=~/.cache/bazel_disk_cache
# Clean the local cache
bazel clean
# Re-run it with `--remote_download_toplevel`
bazel run //tests/multi_repl:c_only_repl --disk_cache=~/.cache/bazel_disk_cache --remote_download_toplevel

The second bazel run should fail with

<command line>: can't load .so/.DLL for: libHStestsZSmultiZUreplZSaZSa.so (libHStestsZSmultiZUreplZSaZSa.so: cannot open shared object file: No such file or directory)

Expected behavior

--remote_download_toplevel shouldn't prevent the repl targets from working

Environment

• OS name + version:
• Bazel version:
• Version of the rules:

Additional context

I guess that's somehow due to these dependencies not being properly declared, although a quick glance at the code doesn't uncover anything obvious

[aherrmann]

There have been some issues around runfiles with builds without the bytes, see bazelbuild/bazel#8899 and bazelbuild/bazel#6862. Though bazelbuild/bazel@11a98a5 claims to have these fixed since Bazel 1.0.0.

haskell_repl does declare runfiles. Printing the inputs variable for the reproduction case shows that _solib_k8/libHStestsZSmultiZUreplZSaZSa-ghc8.6.5.so is included in the list. The filename in the error message doesn't include the GHC version suffix, though that could just be GHC trying different file names.

Another point worth noting, the files under _solib_k8/... are symbolic links. It's possible that the files that the links are pointing to are not automatically captured and we would have to manually include the resolved symlink into the runfiles as well.

[thufschmitt]

Another point worth noting, the files under _solib_k8/... are symbolic links. It's possible that the files that the links are pointing to are not automatically captured and we would have to manually include the resolved symlink into the runfiles as well.

Looks like it indeed. After the second bazel build, the symlink is here, but not its target. I'll try to add it to the runfiles of the target