Allow full control over dyn lib names
This is related to:
- GHC ticket #11587 (closed)
- Cabal issue https://github.com/haskell/cabal/issues/4263
- Cabal PR https://github.com/haskell/cabal/pull/4656
- Cabal PR https://github.com/haskell/cabal/pull/4426
Currently GHC hard codes the naming convention for shared/dynamic libraries. For example:
hs-libraries: HScpu-0.1.2-b25995 in the package registration, on ELF GHC uses the name
libHScpu-0.1.2-b2599-ghc8.0.1.so (and .dynlib on OSX).
This naming convention is based on an old assumption that shared libraries would go in a shared
$libdir, and that all that was needed to ensure uniqueness was the combination of the package id and ghc version.
This assumption is very out of date now. Different install schemes are used by different packaging tools (nix style vs classic style) and sometimes we want shared lib dirs and sometimes not, and of course we all know now that a package id is not nearly enough to ensure file names are unique.
The obvious solution is for GHC to stop making any unnecessary naming convention assumptions and allow specifying the full library name in the package registration information.
We would of course keep the remaining necessary naming convention is the
lib prefix and
.dll suffix, which is the same convention used by the system linker for
- *So specifically:**
- Add a new
dynamic-hs-libraries(to go along with
hs-libraries) to the
ghc-pkgregistration information. This naming convention follows the existing
- When this field is used then these library names will by used for dynamic linking. For backward compatibility, when this field is not supplied then the existing
-ghc8.0.1convention is used.
While we are at it, we should do the same for the
extra-libraries and add a
dynamic-extra-libraries. Note that there is an existing
extra-ghci-libraries which was added for a similar reason (though prior to ghci switching to dynamic libs by default) because in rare cases the dyn libs are just named differently from the static libs, or occasionally there are extra static vs dynamic libs. For example,
pkg-config makes a clear distinction between static and dynamic libs (because dynamic libs only need direct deps whereas static needs the full transitive closure).