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:
For 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 .so
/.dynlib
/.dll
suffix, which is the same convention used by the system linker for -lfoo
vs libfoo.so
.
- *So specifically:**
- Add a new
dynamic-hs-libraries
(to go along withhs-libraries
) to theghc-pkg
registration information. This naming convention follows the existinglibrary-dirs
anddynamic-library-dirs
. - 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.1
convention 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).
Trac metadata
Trac field | Value |
---|---|
Version | 8.2.1 |
Type | Bug |
TypeOfFailure | OtherFailure |
Priority | normal |
Resolution | Unresolved |
Component | Package system |
Test case | |
Differential revisions | |
BlockedBy | |
Related | |
Blocking | |
CC | |
Operating system | |
Architecture |