Depend on crc32c package
#24
Open
Conversation
This file contains hidden or 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
Author
|
NOTE: the PR should probably not be merged as-is. It requires some thought before it is ready. I just opened the PR to open the discussion. |
Owner
|
This sounds reasonable to me. I think it would also make sense to eventually just deprecate our module and suggest users use that dedicated package |
carbolymer
added a commit
to carbolymer/snappy-c
that referenced
this pull request
Oct 29, 2025
Both digest and crc32c are importing crc32c_extend symbol which results in GHC linker fatal error when both dependencies are in the dependency tree. There is a PR open in digest which goes in the direction of removing crc32c C library: TeofilC/digest#24 in favour of using crc32c haskell library directly.
carbolymer
added a commit
to carbolymer/snappy-c
that referenced
this pull request
Nov 3, 2025
Both digest and crc32c are importing crc32c_extend symbol which results in GHC linker fatal error when both dependencies are in the dependency tree. There is a PR open in digest which goes in the direction of removing crc32c C library: TeofilC/digest#24 in favour of using crc32c haskell library directly.
carbolymer
added a commit
to carbolymer/snappy-c
that referenced
this pull request
Nov 3, 2025
Both digest and crc32c are importing crc32c_extend symbol which results in GHC linker fatal error when both dependencies are in the dependency tree. There is a PR open in digest which goes in the direction of removing crc32c C library: TeofilC/digest#24 in favour of using crc32c haskell library directly.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
When cross-compiling to Windows
ouroboros-consensususing Haskell.nix, we encountered the following error:The veredict is that both
crc32canddigest(on which we depend via different dependencies) compile C sources for libcrc32c, and they both expose the same symbols. In a normal Windows build this is not a problem, but it is a problem for the cross-compilation.digesthas a git submodule with Google's crc32c, andcrc32cinstead has a local vendored version of the source code.A possible alternative would be to create a package that prepares the C sources for both
crc32canddigest. In the same spirit as https://hackage.haskell.org/package/zlib-clib.I'm opening this PR as a way to start the discussion on how to best solve this. Unfortunately
digestexposed quite some cabal flags which do not exist incrc32c, so I don't really know how to best proceed.