Doctest failure with foreign import
Describe the bug
- an
haskell_doctestwhich depends on anhaskell_librarya -
acontains doctest statements which which depends on aforeign import ccall "C_SYMBOL_NAME"in the same package. -
adepends on acc_librarybwhich 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.
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.
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.