Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

hashable-1.4.5.0 will break build purity of Haskell packages #318321

Open
TerrorJack opened this issue Jun 8, 2024 · 1 comment
Open

hashable-1.4.5.0 will break build purity of Haskell packages #318321

TerrorJack opened this issue Jun 8, 2024 · 1 comment

Comments

@TerrorJack
Copy link
Contributor

TerrorJack commented Jun 8, 2024

Describe the bug

hashable-1.4.5.0 has been released on Hackage and may be propagated into a Stackage LTS and the Haskell package set here some time later. It includes a package flag arch-native that defaults to True, which means it enables -march=native in order to harvest SIMD speedup when compiling the vendored xxhash cbits.

This will cause the binaries built by Hydra depend on the specific CPU models of the builders. AFAIK in nixpkgs, the C/C++ compiler wrapper scripts do not contain logic to filter out -march=native, and packages that involve -march=native should be explicitly marked with impureUseNativeOptimizations. Given hashable is a very common Haskell dependency, before the real damage is caused downstream, I'd like to raise awareness of the potential issue here so the nixpkgs Haskell maintainers can apply the appropriate overrides when hashable is bumped in the package set.

Upstream issue (closed at the time of writing this one): haskell-unordered-containers/hashable#308

Notify maintainers

@domenkozar @maralorn @sternenseemann


Add a 👍 reaction to issues you find important.

@TerrorJack
Copy link
Contributor Author

Update: after taking a quick look at output of $CC -march=native -v in a nix shell, the -march=native seems to be automatically rewritten to '-mtune=generic' '-march=x86-64'. So it seems we're good here, feel free to close this issue any time, but it would be nice for someone more familiar with wrapper logic to take a closer look to confirm.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

No branches or pull requests

1 participant