-
Julian Ospald authored
Motivation ---------- Often times, the user facing `ghc` binary is symlinked by other forces, such as the package manager, tooling like ghcup etc. As such, the naming convention (version suffix in particular) may not align with the assumptions made in Cabal and it may find an incorrect ghc-pkg. See: - https://github.com/haskell/cabal/issues/7390 - ghc/ghc#18807 - haskell/ghcup-hs#73 Solution -------- Guessing the ghc-pkg path is already a hack and will be solved more appropriately in the future, see - ghc/ghc!4214 - ghc/ghc$2710 These patches will solve the issue for future GHC versions. As such, this patch provides a workaround for older, already existing GHC versions by first always following the symbolic link of the ghc binary (if it is one) and prefering its target directory as the guess lookup location. Rationale --------- The canonicalized path of the ghc binary usually points to the bin/ directory unpacked from a bindist, which is less likely to be tampered with by distributions and tools. As such, prefering the canoncialized path should get us more robust results.