Profiled builds of Cabal packages with Template Haskell fail with static RTS

aherrmann commented 4 years ago

Describe the bug Building a Cabal package in profiling mode with GHC using the static RTS fails with an error of the form

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

To Reproduce

Check out https://github.com/digital-asset/daml.git at revision 49a66515bde39e3ab56b5a63bcce7cf70936edd9
Execute bazel build @stackage//:generics-sop -c dbg

Observe the following error

Use --sandbox_debug to see verbose messages from the sandbox
<command line>: can't load .so/.DLL for: libHSsop-core-0.4.0.0.so (libHSsop-core-0.4.0.0.so: cannot open shared object file: No such file or directory)
Traceback (most recent call last):
File ".../sandbox/linux-sandbox/621/execroot/com_github_digital_asset_daml/bazel-out/k8-dbg/bin/external/rules_haskell/haskell/cabal_wrapper.runfiles/rules_haskell/haskell/cabal_wrapper.py", line 182, in <module>
  run([runghc, setup, "build", "--verbose=0", "--builddir=" + distdir])
File ".../sandbox/linux-sandbox/621/execroot/com_github_digital_asset_daml/bazel-out/k8-dbg/bin/external/rules_haskell/haskell/cabal_wrapper.runfiles/rules_haskell/haskell/cabal_wrapper.py", line 42, in run
  subprocess.run(cmd, check=True, stdout=subprocess.PIPE, stderr=subprocess.PIPE, *args, **kwargs)
File "/nix/store/vs4vj1yzqj1bkcqkf3b6sxm6jfy1gb4j-python3-3.7.7/lib/python3.7/subprocess.py", line 512, in run
  output=stdout, stderr=stderr)
subprocess.CalledProcessError: Command '['.../sandbox/linux-sandbox/621/execroot/com_github_digital_asset_daml/external/rules_haskell_ghc_nixpkgs/bin/runghc', '.../sandbox/linux-sandbox/621/execroot/com_github_digital_asset_daml/external/stackage/generics-sop-0.4.0.1/Setup.hs', 'build', '--verbose=0', '--builddir=/tmp/tmp33e36rtq']' returned non-zero exit status 1.
Target //compiler/damlc:damlc failed to build
ERROR: .../daml/compiler/damlc/BUILD.bazel:10:1 HaskellCabalLibrary @stackage//:generics-sop failed (Exit 1) cabal_wrapper failed: error executing command 
(cd .../sandbox/linux-sandbox/621/execroot/com_github_digital_asset_daml && \
exec env - \
  LANG=C.UTF-8 \
  LOCALE_ARCHIVE=external/glibc_locales/lib/locale/locale-archive \
  PATH=bazel-out/k8-dbg/bin/external/alex/_install/bin:bazel-out/k8-dbg/internal/_middlemen:bazel-out/k8-dbg/bin/external/c2hs/_install/bin:bazel-out/k8-dbg/internal/_middlemen:bazel-out/k8-dbg/bin/external/happy/_install/bin:bazel-out/k8-dbg/internal/_middlemen:/nix/store/xxnf0clrl91f1xcj6h9hcm220mh2m5pm-posix-toolchain/bin \
bazel-out/k8-dbg/bin/external/rules_haskell/haskell/cabal_wrapper lib:generics-sop generics-sop-0.4.0.1 false external/stackage/generics-sop-0.4.0.1/Setup.hs external/stackage/generics-sop-0.4.0.1 bazel-out/k8-dbg/bin/external/stackage/generics-sop-0.4.0.1/_install/generics-sop-0.4.0.1.conf.d '--flags=' '--ghc-option=-w' '--ghc-option=-optF=-w' -- '--package-db=bazel-out/k8-dbg/bin/external/stackage/sop-core-0.4.0.0/_install/sop-core-0.4.0.0.conf.d' --enable-profiling '--with-alex=bazel-out/k8-dbg/bin/external/alex/_install/bin/alex' '--with-c2hs=bazel-out/k8-dbg/bin/external/c2hs/_install/bin/c2hs' '--with-happy=bazel-out/k8-dbg/bin/external/happy/_install/bin/happy')
Execution platform: @io_tweag_rules_nixpkgs//nixpkgs/platforms:host

Expected behavior The build should succeed.

Environment

OS name + version: Ubuntu 19.10
Bazel version: 2.1.0
Version of the rules: 1726f672e8d0504c4214ccf52ba194016d077c6e

Additional context The build fails on what looks like a GHCi linker error when it tries to link the library for the package sop-core. The error message mentions libHSsop-core-0.4.0.0.so without the usual GHC version suffix, this usually means that GHC is really looking for libHSsop-core-0.4.0.0.a. Looking at the artifacts produced by Cabal building sop-core we see that it produces libHSsop-core-0.4.0.0.a and libHSsop-core-0.4.0.0_p.a. However, rules_haskell only tracks the _p.a output in profiling mode meaning that the plain .a will not be made available to any actions down the line depending on sop-core. A possible solution might be to track the plain .a output as well and make it available to the Cabal build action.

aherrmann commented 4 years ago

The issue seems to be that Cabal with --enable-profiling builds both a profiled and a non-profiled version of the library. Building template Haskell in the non-profiled version will require non-profiled versions of dependencies in scope. As a proof of concept, setting --ghc-options=-prof works around the issue. Cabal will still produce both a _p.a and a .a however since -prof is set on both, GHC will be able to compile template Haskell using the dependency's _p.a output in both cases.

guibou commented 4 years ago

The issue seems to be that Cabal with --enable-profiling builds both a profiled and a non-profiled version of the library

I described this behavior in #438.

rules_haskell is currently using an approach to profiling (-fexternal-interpreter) which is not used by the rest of the world. cabal is not using it. stack is not using it. So we are facing a lot of bug because as far as I know, we are the only users of this feature.

guibou commented 4 years ago

tweag / rules_haskell

Profiled builds of Cabal packages with Template Haskell fail with static RTS #1353