rules_haskell
rules_haskell copied to clipboard
Profiled builds with C dependencies fail.
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.
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-interpreter
depending 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
I workaround this issue with the following, only in profiling mode (with select
), I:
- remove the
cbits
dependencies from thedeps
attribute of myhaskell_library
. That's easy, mostcbits
dependencies do only have one parent. This is a huge pain becauseselect
are not iterable. - add back the
cbits
dependencies to thedeps
of allhaskell_binary
. That's manual and I'm doing that in our customhaskell_binary
macro for each existingcbits
dependencies.