Support using TH and FFI with static C dependencies #1582
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
aherrmann
reviewed
Aug 17, 2021
aherrmann
approved these changes
Aug 18, 2021
Consider the following scenario:
- Package H1 uses FFI and needs to be linked against
a pre-built static library X
- Package H2 depends on H1 and uses TH (but TH code doesn't
depend on X)
- The ghc in the toolchain doesn't have a static runtime
In this case, as far as I can see, it is not currently possible
to build H2 using `haskell_library`: during the compile step,
`-lX` is passed to ghc, and the moment TH is used, ghc will try
to load `libX.a` and fail. For example, on the added test-case,
I currently see:
```
$ bazel build //tests/library-with-static-cc-dep:mypkg
INFO: Analyzed target //tests/library-with-static-cc-dep:mypkg (10 packages loaded, 372 targets configured).
INFO: Found 1 target...
ERROR: /home/daniel/repos/rules_haskell/tests/library-with-static-cc-dep/BUILD.bazel:10:16: HaskellBuildLibrary //tests/library-with-static-cc-dep:mypkg failed: (Exit 1): ghc_wrapper failed: error executing command bazel-out/host/bin/haskell/ghc_wrapper bazel-out/k8-fastbuild/bin/tests/library-with-static-cc-dep/compile_flags_mypkg_HaskellBuildLibrary ... (remaining 1 argument(s) skipped)
Use --sandbox_debug to see verbose messages from the sandbox
<command line>: User-specified static library could not be loaded (bazel-out/k8-fastbuild/bin/tests/library-with-static-cc-dep/libcbits-static.a)
Loading static libraries is not supported in this configuration.
Try using a dynamic library instead.
...
```
Cabal on the other hand doesn't pass `-lX` to ghc in this case,
so falling back to `haskell_cabal_library` is the only workaround I see.
To fix this in haskell_library, the proposed solution is to
optimistically ignore the static dependencies during the compile
action whenever the ghc runtime will not be able to load them.
The only visible difference to the user should be when their TH
code in H2 depends in fact on X (a case that could never work under
this scenario anyway): now they will get a symbol-not-found error,
instead of a failure to load the static lib.
thufschmitt
force-pushed
the
th_ffi_static
branch
from
2727327 to
a282750
Compare
|
@Mergifyio refresh |
|
Command
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Consider the following scenario:
In this case, as far as I can see, it is not currently possible to build H2 using
haskell_library: during the compile step,-lXis passed to ghc, and the moment TH is used, ghc will try to loadlibX.aand fail. For example, on the added test-case, I currently see:Cabal on the other hand doesn't pass
-lXto ghc in this case, so falling back tohaskell_cabal_libraryis the only workaround I see.To fix this in haskell_library, the proposed solution is to optimistically ignore the static dependencies during the compile
action whenever the ghc runtime will not be able to load them. The only visible difference to the user should be when their TH
code in H2 depends in fact on X (a case that could never work under this scenario anyway): now they will get a symbol-not-found error, instead of a failure to load the static lib.