Enable Cabal's own RPATH handling on *BSD and Solaris

[depressed-pho]

Cabal is confirmed to be capable of handling RPATH on these platforms.

---

Please include the following checklist in your PR:

• Patches conform to the coding conventions.
• Any changes that could be relevant to users have been recorded in the changelog.
• The documentation has been updated, if necessary.

[angerman]

@depressed-pho but do we want cabal to handle rpath logic? Or do we want GHC to handle rpath logic? At least on Darwin there is a strong case to be made for GHC to handle rpath logic, as ghc can control the linking more precisely. If cabal passes -rpath to ghc, it will just pass that on verbatim. Whereas when GHC is responsible for -rpath injection, it can make adjustments that suite the target better than just having to verbatim pass on the linker arguments. I'm not saying this isn't a good change, I'm just weary if cabal should even be doing this in the first place. See also #7094

[depressed-pho]

@depressed-pho but do we want cabal to handle rpath logic? Or do we want GHC to handle rpath logic? At least on Darwin there is a strong case to be made for GHC to handle rpath logic, as ghc can control the linking more precisely. If cabal passes -rpath to ghc, it will just pass that on verbatim. Whereas when GHC is responsible for -rpath injection, it can make adjustments that suite the target better than just having to verbatim pass on the linker arguments. I'm not saying this isn't a good change, I'm just weary if cabal should even be doing this in the first place. See also #7094

We do want Cabal to handle it. Suppose we have a Cabal package which defines a library, and also an executable that depending on the library. Without Cabal's rpath logic, GHC would link the executable with an rpath pointing at the build directory, not the final destination where the library is going to be installed. This is because GHC doesn't know that the library will be placed somewhere else, and only Cabal knows that (and correctly handles that for Linux atm).

[angerman]

@depressed-pho but do we want cabal to handle rpath logic? Or do we want GHC to handle rpath logic? At least on Darwin there is a strong case to be made for GHC to handle rpath logic, as ghc can control the linking more precisely. If cabal passes -rpath to ghc, it will just pass that on verbatim. Whereas when GHC is responsible for -rpath injection, it can make adjustments that suite the target better than just having to verbatim pass on the linker arguments. I'm not saying this isn't a good change, I'm just weary if cabal should even be doing this in the first place. See also #7094

We do want Cabal to handle it. Suppose we have a Cabal package which defines a library, and also an executable that depending on the library. Without Cabal's rpath logic, GHC would link the executable with an rpath pointing at the build directory, not the final destination where the library is going to be installed. This is because GHC doesn't know that the library will be placed somewhere else, and only Cabal knows that (and correctly handles that for Linux atm).

Fair, but in that case Cabal needs to replicate the stripping and post link fixup logic GHC currently has; which to me does not seem very elegant, especially as cabal than needs to keep up to date what is fixed in ghc.

This might be an ELF / MachO issue, but I would believe that install_name_tool should be able to correct library locations.

[Kleidukos]

Marking this PR as draft 🙂