You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
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 flagarch-native
that defaults toTrue
, which means it enables-march=native
in order to harvest SIMD speedup when compiling the vendoredxxhash
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 withimpureUseNativeOptimizations
. Givenhashable
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 whenhashable
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.
The text was updated successfully, but these errors were encountered: