hashable-1.4.5.0 will break build purity of Haskell packages

[TerrorJack]

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]

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.

[sternenseemann]

Yes, that is correct. Also it does seem unlikely we'll end up with 1.4.5.0 in an LTS snapshot. Current LTS seems to be sticking to 1.4.4.0 for some reason and Nightly is already using 1.4.7.0.