GHC.Paths makes incorrect assumption as to where to find ghc

[erikd]

I hen trying to set up taffybar (xmonad toolbar) which uses Dyre which in turn uses ghc-paths and ran into a problem.

I have a couple of different versions of GHC installed (7.4.2, 7.6.3 and 7.7) all installed under $HOME/GHC/$version and I switch between them by setting my $PATH variable. When Dyre tires to re-compile the taffybar config file, ghc-paths says that the ghc binary is at "/usr/lib/ghc/bin/ghc-7.6.3" when it is actually at $HOME/GHC/7.6.3/bin/ghc-7.6.3.

[andreasabel]

I am having a similar problem: the value of ghc points to a location where my GHC used to be. The explanation is that the path to ghc is fixed at compile-time of ghc-paths, and neither Stack nor Cabal rebuild this package when the location of GHC changes.

This has already described by @phadej in his answer at https://stackoverflow.com/questions/38096298/where-is-the-source-of-ghc-paths-value-came-from .

... If it still shows "/usr/bin/ghc-7.10.3" for GHC paths, then I suspect that you had GHC there when you compiled ghc-paths for GHC-7.10.3, and as stack is quite good in not rebuilding stuff, the old version of ghc-paths is still there. I don't know a way to rebuild a package in a snapshot, other then whiping ~/.stack and starting over; which might be a good idea. if you changed you global GHC stuff.

Given this problem, I have doubts in the quality of the ghc-paths package. The solution chosen here does not work reliably in the current Haskell ecosystem, where the location of the compiler is not counted as dependency whose modification warrants recompilation.

[sol]

The solution chosen here does not work reliably in the current Haskell ecosystem, where the location of the compiler is not counted as dependency whose modification warrants recompilation.

1. It has been working for me reliably for over 15 years, but then again, reinstalling the exact same version of GHC into a different location is not a use case that I regularly encounter. Also note that with recent version of GHC if you use two GHCs with the exact same version, that are not ABI compatible, then cabal will rebuild ghc-paths (and with older versions of GHC your cabal store would get corrupted anyway). So I think this could only ever be an issue when ABI compatible versions of GHC are installed to different locations. Is this in the context of Nix, or where exactly do you encounter this?
2. Maybe a solution could be for cabal to include the canonical path to GHC into the build hash. However, if this is something you want to pursue, the we will need --with-repl first, otherwise cabal-doctest will fall apart.

[andreasabel]

... Is this in the context of Nix, or where exactly do you encounter this?

I had first installed GHC 9.4.8 in the /usr/local structure going the manual way of downloading, ./configure, make install. Then I removed it and instead installed it with ghcup.
Neither Cabal nor Stack took notice of this, so the ghc-paths build they reused was stale and returned the wrong path.