rules_haskell icon indicating copy to clipboard operation
rules_haskell copied to clipboard

Doctest failure with foreign import

Open guibou opened this issue 4 years ago • 2 comments

Describe the bug

  • an haskell_doctest which depends on an haskell_library a
  • a contains doctest statements which which depends on a foreign import ccall "C_SYMBOL_NAME" in the same package.
  • a depends on a cc_library b which defines the needed C symbol.

running the doctest will fail with the following message:

expected: 
 but got: ghc: ^^ Could not load 'C_SYMBOL_NAME', dependency unresolved. See top entry above.
          ^
        
          ByteCodeLink: can't find label
          During interactive linking, GHCi couldn't find the following symbol:
            C_SYMBOL_NAME
          This may be due to you not asking GHCi to load extra object files,
          archives or DLLs needed by your current session.  Restart GHCi, specifying
          the missing library using the -L/path/to/object/dir and -lmissinglibname
          flags, or simply by naming the relevant files on the GHCi command line.
          Alternatively, this link failure might indicate a bug in GHCi.
          If you suspect the latter, please send a bug report to:
            [email protected]

To Reproduce

Write a setup like what is described in the previous message, such as:

diff --git a/tests/haskell_doctest/BUILD.bazel b/tests/haskell_doctest/BUILD.bazel
index 45628251..2ef13703 100644
--- a/tests/haskell_doctest/BUILD.bazel
+++ b/tests/haskell_doctest/BUILD.bazel
@@ -13,6 +13,11 @@ haskell_library(
     ],
 )
 
+haskell_doctest(
+    name = "works_with_direct_CC_deps",
+    deps = [":lib-a"]
+)
+
 haskell_library(
     name = "lib-b",
     srcs = [

On top of current master. Run it with:

$ bazel build //tests/haskell_doctest:works_with_direct_CC_deps
INFO: Analyzed 13 targets (0 packages loaded, 0 targets configured).
INFO: Found 13 targets...
ERROR: /home/guillaume/tweag/rules_haskell/tests/haskell_doctest/BUILD.bazel:16:16: HaskellDoctest //tests/haskell_doctest:works_with_direct_CC_deps failed: (Exit 1): bash failed: error executing command /nix/store/r4grdrilb0ii0c8vwgwbz6jm67490x8i-bash/bin/bash -c ... (remaining 48 argument(s) skipped)
Loaded package environment from bazel-out/k8-fastbuild/bin/tests/haskell_doctest/compile-package_env-lib-a
Loaded package environment from bazel-out/k8-fastbuild/bin/tests/haskell_doctest/compile-package_env-lib-a
Loaded package environment from bazel-out/k8-fastbuild/bin/tests/haskell_doctest/compile-package_env-lib-a
Loaded package environment from bazel-out/k8-fastbuild/bin/tests/haskell_doctest/compile-package_env-lib-a
tests/haskell_doctest/Foo.hs:11: failure in expression `foo'
expected: 5
 but got: ghc: ^^ Could not load 'c_add_one', dependency unresolved. See top entry above.
          
          
          ByteCodeLink: can't find label
          During interactive linking, GHCi couldn't find the following symbol:
            c_add_one
          This may be due to you not asking GHCi to load extra object files,
          archives or DLLs needed by your current session.  Restart GHCi, specifying
          the missing library using the -L/path/to/object/dir and -lmissinglibname
          flags, or simply by naming the relevant files on the GHCi command line.
          Alternatively, this link failure might indicate a bug in GHCi.
          If you suspect the latter, please send a bug report to:
            [email protected]
          

Examples: 1  Tried: 1  Errors: 0  Failures: 1
INFO: Elapsed time: 0.421s, Critical Path: 0.32s
INFO: 2 processes: 2 internal.
FAILED: Build did NOT complete successfully

Expected behavior

Should not fail.

Additional context

There is a WORKAROUND for this issue. Just write an intermediate haskell_library with no srcs and which depends on the cc_library, such as the following:

haskell_library(
        name = "lib-a-indirect",
        srcs = [],
        deps = ["lib-a"],
        )

haskell_doctest(
    name = "works_with_indirect_CC_deps",
    deps = [":lib-a-indirect"]
)

Here bazel build //tests/haskell_doctest:works_with_indirect_CC_deps builds fine.

guibou avatar Jun 23 '21 16:06 guibou

The workaround does not work on all contexts unfortunately.

Another workaround I found (this is super ugly):

I have an haskell_binary which depends (in deps) on my lib-a-indirect and which have the linkstatic=True attribute.

If I build this target FIRST, then build my doctest, it does not fail.

I'm trying to build a repro for this special context since a few hours, but as always, I'm stuck. I'm comenting mostly for another lost soul, you may want to use that poorly defined workaround.

guibou avatar Dec 13 '21 23:12 guibou

If I build this target FIRST, then build my doctest, it does not fail.

Thanks for the update. This sounds scary, it sounds like an undeclared dependency that somehow becomes available if builds are sequenced this way.

aherrmann avatar Dec 17 '21 12:12 aherrmann