search

input-output-hk / haskell.nix

Alternative Haskell Infrastructure for Nixpkgs
https://input-output-hk.github.io/haskell.nix
Apache License 2.0
551 stars 237 forks source link

New `bitvec` produces broken object files due to CPU model probing #2047

Closed michaelpj closed 6 months ago

michaelpj commented 1 year ago

bitvec-1.1.5.0 now has a simd flag (on by default) which tries to use SIMD operations for things. The implementation of this apparently does some probing for CPU features. I think this is just not available in the Nix sandbox, since we get errors like this:

[ 16 of 173] Compiling PlutusCore.Version ( plutus-core/src/PlutusCore/Version.hs, dist/build/PlutusCore/Version.o, dist/build/PlutusCore/Version.dyn_o )
ghc-iserv: /nix/store/z9kvc0w7np3z1hc2bh3bhlq9vq9a4qsd-bitvec-lib-bitvec-1.1.5.0/lib/x86_64-linux-ghc-8.10.7/bitvec-1.1.5.0-Le2irhQes6H3DV4uWDzYLr/HSbitvec-1.1.5.0-Le2irhQes6H3DV4uWDzYLr.o: unknown symbol `__cpu_model'
ghc-iserv: Could not load Object Code /nix/store/z9kvc0w7np3z1hc2bh3bhlq9vq9a4qsd-bitvec-lib-bitvec-1.1.5.0/lib/x86_64-linux-ghc-8.10.7/bitvec-1.1.5.0-Le2irhQes6H3DV4uWDzYLr/HSbitvec-1.1.5.0-Le2irhQes6H3DV4uWDzYLr.o.
ghc-iserv: /nix/store/z9kvc0w7np3z1hc2bh3bhlq9vq9a4qsd-bitvec-lib-bitvec-1.1.5.0/lib/x86_64-linux-ghc-8.10.7/bitvec-1.1.5.0-Le2irhQes6H3DV4uWDzYLr/HSbitvec-1.1.5.0-Le2irhQes6H3DV4uWDzYLr.o: unknown symbol `__cpu_model'
ghc-iserv: Could not load Object Code /nix/store/z9kvc0w7np3z1hc2bh3bhlq9vq9a4qsd-bitvec-lib-bitvec-1.1.5.0/lib/x86_64-linux-ghc-8.10.7/bitvec-1.1.5.0-Le2irhQes6H3DV4uWDzYLr/HSbitvec-1.1.5.0-Le2irhQes6H3DV4uWDzYLr.o.
ghc-iserv: /nix/store/z9kvc0w7np3z1hc2bh3bhlq9vq9a4qsd-bitvec-lib-bitvec-1.1.5.0/lib/x86_64-linux-ghc-8.10.7/bitvec-1.1.5.0-Le2irhQes6H3DV4uWDzYLr/HSbitvec-1.1.5.0-Le2irhQes6H3DV4uWDzYLr.o: unknown symbol `__cpu_model'
ghc-iserv: Could not load Object Code /nix/store/z9kvc0w7np3z1hc2bh3bhlq9vq9a4qsd-bitvec-lib-bitvec-1.1.5.0/lib/x86_64-linux-ghc-8.10.7/bitvec-1.1.5.0-Le2irhQes6H3DV4uWDzYLr/HSbitvec-1.1.5.0-Le2irhQes6H3DV4uWDzYLr.o.

Then again, these are also from ghc-iserv, so this might only manifest when there are TH splices involved. I'm not 100% sure, but turning off the simd flag fixes it.

Reproducible on cardano-node if you bump the index state to allow the newer bitvec and turn the simd flag on.

michaelpj commented 1 year ago

It's also not easy to avoid this dependency, since it's a transitive dependency of criterion.

michaelpj commented 1 year ago

Hmm, apparently the symbol has been private for a long time? https://github.com/baldurk/renderdoc/issues/365

michaelpj commented 1 year ago

Maybe you just have to link against libgcc?

michaelpj commented 1 year ago

Okay, I tried forcing gcc into pakcages.bitvec.library.libs and it didn't help. I'm just going to leave this for someone who has a better idea what is going on.

michaelpj commented 1 year ago

Ah of course: cardano-node sets -fexternal-interpreter for plutus-core to work around a different weird issue we had. So perhaps this only appears if you're using the external interpreter.

stale[bot] commented 8 months ago

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.