search

NixOS / nixpkgs

Nix Packages collection & NixOS
MIT License
18.35k stars 14.31k forks source link

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

Open TerrorJack opened 5 months ago

TerrorJack commented 5 months ago

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): https://github.com/haskell-unordered-containers/hashable/issues/308

Notify maintainers

@domenkozar @maralorn @sternenseemann

Add a :+1: reaction to issues you find important.

TerrorJack commented 5 months ago

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 commented 1 month ago

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.