Backport Unique widening [9.8]
This backports the fix to #22010 (closed), as well as parts of !10448 (merged) (which eliminates the dependence on Unique
in the BRK_FUN
bytecode instruction as using Word64
in this context would complicate the interpreter).
Merge request reports
Activity
added backport label
assigned to @bgamari
changed milestone to %9.8.4
added 1 commit
- e267aa7f - hadrian-ghci-multi: Pass -this-package-name in unit response files
mentioned in issue #25432 (closed)
this backported unused includes which were later removed but the removal was not backported
upgrading to 9.8.4 gives us an error now (in a nix env that tries to build ghc-lib)
ghc-lib-ghc> GHC/Data/Word64Set.hs:7:2: error: ghc-lib-ghc> fatal error: containers.h: No such file or directory ghc-lib-ghc> 7 | ghc-lib-ghc> | ^ ghc-lib-ghc> | ghc-lib-ghc> 7 | ghc-lib-ghc> | ^ ghc-lib-ghc> compilation terminated.
currently working around this with a patch that adds an empty header file
Edited by David HewsonI tried adding --verbose to cpp flags in Hadrian system.config and I can see when Word64Set.hs is preprocessed that
-I libraries/containers/containers/include
is present. So the CI here is if course finding the header from the containers package and not failing.As for why haskellNix fails, it seems that they declare a cabal project for "all" the provided libraries that ghc offers, and for whatever reason that does not result in the includes of containers being added to search path.
https://github.com/input-output-hk/haskell.nix/blob/master/overlays%2Fghc-packages.nix#L102
this is where hadrian adds the includeDirs of dependencies
not up to me if this is right or wrong but i think this is the key difference compared with what haskellNix is doing when trying to build the packages
looking again it seems to me that the path inside
_build
is correct, i think this is the "installed" package location (??), that include directory does not exist since containers installs no headers, but forrts
for example it does contain the listed headers.however both the installed include dir and the original install dir are included. i'm not quite sure how they both end up there though, they're coming from depIncludeDirs but i can't see why both
'-I' '/home/david/repos/ghc/libraries/containers/containers/include' '-I' '/home/david/repos/ghc/_build/stage1/libraries/containers/containers/build/include'
I have created a reproducer for this with a minimal haskell.nix stack project.
See: #25567 (closed)
awesome thanks @teo
mentioned in issue #25567 (closed)