-dynload is a misfeature #11221
Description
GHC has a -dynload flag, which has two options: deploy and sysdep. This allows controlling ghc to either inject rpaths based on the packages it's trying to link an executable against, or (in the case of deploy, not set them).
The use of -dynload deploy was initially implemented in #2255 (commits: 06a713e, 6c9dce4) a decade ago by @christiaanb for cabal deploy (which I don't think ever materialized).
cabal-install uses this feature to prevent ghc from passing rpath arguments to the linker. And then passes -optl-Wl,-rpath,... to ghc for all package libraries, and thanks to @alt-romes fix in addbcbf also for --extra-library-paths.
This whole concept muddles a clean separation between ghc, and cabal, by cabal taking responsibility for something ghc should take care of.
- Should cabal pass the
-rpathfor--extra-library-paths?
I do think yes, it should.
- Should cabal pass -dynload deploy?
I do not think so. I think cabal should let ghc handle this, and defer this to GHC. It should be none of cabals business, the relevant metadata is encoded in the package database, and ghc should use that declaratively, instead of being told to not use it, and then have cabal pass some extra linker flags outside of ghc. This just gives ghc much less control over the linking process, and means ghc and cabal can end up disagreeing on this.
- What about that hypothetical cabal deploy command?
If cabal is to be used to move/package/bundle/deploy a dynamically linked program. First of all, I'd like to ask if this is really something cabal-install should assume, or if this isn't better left to third party applications to do?
Should cabal end up wanting to assume this functionality, my preferred approach would be that cabal instead rewrites the RPATHs in the executable after ghc has built them, as a separate step, not by trying to interfere with ghc. This tight coupling of ghc and cabal just leads to interlocking and brittleness, in which both projects need to be very careful about the other.