Open aherrmann opened 4 years ago
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:
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.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.
Describe the bug Building a target with a C dependency fails in profiling mode
To Reproduce
Expected behavior The build should succeed.
Environment
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 correspondingdynamic-library-dirs
field, instead it is looking in thelibrary-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.