Profiled builds with C dependencies fail.

[aherrmann]

Describe the bug Building a target with a C dependency fails in profiling mode

To Reproduce

$ bazel build //tests/library-with-sysincludes -c dbg
...
<command line>: libexternal_Szlib_Slibzlib.so: cannot open shared object file: No such file or directory
Target //tests/library-with-sysincludes:library-with-sysincludes failed to build
...

Expected behavior The build should succeed.

Environment

• OS name + version: Ubunuto 19.10
• Bazel version: 2.1.0
• Version of the rules: 98e3fb73dca350c12892ec6476a3bb80a04d87b4

Additional context The library libexternal_Szlib_Slibzlib.so is an input to the build action and can be found in the sandbox. However, GHC is not looking for the library in the corresponding dynamic-library-dirs field, instead it is looking in the library-dirs field where the .a version would be present if it were an input to the build action. The reason seems to be that we define -fexternal-interpreter in profiling mode, which means that GHC doesn't look for dynamic libraries (as would be required by the dynamic RTS) but instead looks for static libraries.

[aherrmann]

Providing static versions of C library dependencies instead in case of -prof -fexternal-interpreter breaks another test-case, //tests/template-haskell-with-cbits. The difference is that in this test case the C library is a direct dependency of the package using template Haskell, whereas in //tests/library-with-sysinclude it is an indirect dependency. GHC seems to inconsistent about whether it expects static or dynamic C libraries with -fexternal-interpreterdepending on whether a C library is a direct or indirect dependency. I've raised a ticket about this on GHC: https://gitlab.haskell.org/ghc/ghc/issues/18317

[guibou]

I workaround this issue with the following, only in profiling mode (with select), I:

• remove the cbits dependencies from the deps attribute of my haskell_library. That's easy, most cbits dependencies do only have one parent. This is a huge pain because select are not iterable.
• add back the cbits dependencies to the deps of all haskell_binary. That's manual and I'm doing that in our custom haskell_binary macro for each existing cbits dependencies.