Stack can't be built with 32-bit GHC >= 9.2.2, due to its `basement` dependency

[ii8]

On a 32bit linux machine if I try to compile stack this error occurs:

[19 of 84] Compiling Basement.Numerical.Conversion ( Basement/Numerical/Conversion.hs, dist/build/Basement/Numerical/Conversion.o, dist/build/Bal/Conversion.dyn_o )
Basement/Numerical/Conversion.hs:29:1: error: [GHC-87110]
     Could not find module ‘GHC.IntWord64’.
     Use -v to see a list of the files searched for.
    |
 29 | import GHC.IntWord64
    | ^^^^^^^^^^^^^^^^^^^^
 [20 of 84] Compiling Basement.Numerical.Number ( Basement/Numerical/Number.hs, dist/build/Basement/Numerical/Number.o, dist/build/Basement/Numer_o )
 [22 of 84] Compiling Basement.Types.Char7 ( Basement/Types/Char7.hs, dist/build/Basement/Types/Char7.o, dist/build/Basement/Types/Char7.dyn_o )
 [23 of 84] Compiling Basement.Base16  ( Basement/Base16.hs, dist/build/Basement/Base16.o, dist/build/Basement/Base16.dyn_o )
 Error: cabal: Failed to build basement-0.0.16 (which is required by stack-3.7.1).

OS: Void linux
arch: i686
stack version: 3.7.1
ghc version: 9.8.4

[mpilgrem]

@ii8, thanks for reporting.

I think a solution may be to:

• fork the basement package (see further below);
• apply this patch to basement published by @juhp: i386 build fails: import GHC.IntWord64 haskell-foundation/foundation#565 (comment); and
• edit Stack's package.yaml to build Stack against that fork.

-oOo-

The Stack project itself dropped 32 bit machine architectures in 2020 (before my time): https://docs.haskellstack.org/en/stable/ChangeLog/#v231-2020-04-29

GHCup builds Stack for a wider variety of platforms. However, it stopped providing 32 bit Stack after Stack 2.9.3 - see https://github.com/haskell/ghcup-metadata/blob/develop/ghcup-0.0.9.yaml. (I am not sure how it did that, because the 'official' version of Stack 2.9.3 was built using Stackage LTS 20.0/GHC 9.2.5 - see further below.)

Looking at your error message:

• basement depends on ghc-prim (a GHC wired-in boot package, which means the boot package cannot be shadowed by a different version of the same package - see the note at: https://docs.haskellstack.org/en/stable/configure/yaml/project/#extra-deps);
• ghc-prim >= 0.8.0 (released 2021-10-29) no longer exposes module GHC.IntWord64 - see https://hackage.haskell.org/package/ghc-prim; and
• GHC >= 9.2.2 come with ghc-prim >= 0.8.0 (see https://github.com/commercialhaskell/stackage-content/blob/master/stack/global-hints.yaml)

The basement problem is documented here, at its archived GitHub repository:

• i386 build fails: import GHC.IntWord64 haskell-foundation/foundation#565

The primary maintainer of basement has said (at least, in respect of other Haskell packages) that he does not intend to develop them further or to introduce new maintainers. I am currently investigating if that state of affairs applies to basement. See: https://discourse.haskell.org/t/fork-memory-as-memoria/11777/16?u=mpilgrem. Currently, it appears to me that it does apply.

[mpilgrem]

How Stack 3.7.1 depends on basement:

[ii8]

Oh wow there's a whole backstory to this commercialhaskell/stackage#7336
I'm surprised this fellow has come to the conclusion that not passing on maintainership and letting packages bitrot for years for which they will inevitably continue to be used is a net security benefit.

Thank you for the wealth of information, much appreciated. I'll see if I can convince cabal to let me patch packages between fetching and building.

[juhp]

Indeed it is possible: https://koji.fedoraproject.org/koji/buildinfo?buildID=2696940
(I haven't tried ghc-9.10 yet...)