-
Notifications
You must be signed in to change notification settings - Fork 85
arch-native defaults to True which is dangerous #308
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
Comments
But if It's a trade-off, and in perfect world the whole tooling ( There are also plenty of packages on Hackage which have flags like And GHC todays leaves a probably noticeable performacne on the table, e.g. if you have a code which uses |
I'll add, that And figuring out you need to turn a package flag is a lot less work then e.g. fixing issues like ndmitchell/hlint#1533, which is arguably the same problem: the binary for distribution is not built to be as widely usable as it could. |
I was bitten hard by this change. It took quite some time to reach here from my server written with Servant crashing with an unfamiliar message At least I'm relieved to know that there is a "quite significant performance boost" which could justify the tradeoff. But I wish the change would have been emphasized much more, for example by incrementing the major version number. |
It's appreciated that the caveat of
arch-native
(creating non-portable binary due to-march=native
) is documented and visible on the hackage page. But IMHO this is still dangerous, because downstream project authors may not audit all their dependency upgrades, and this looks incredibly likely to sneak into downstream build plans and making downstream CI pipelines produce binaries that crash at runtime on machines with CPUs older than GH action runners.The text was updated successfully, but these errors were encountered: