#14182: Allow full control over dyn lib names -------------------------------------+------------------------------------- Reporter: duncan | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Package | Version: 8.2.1 system | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This is related to: * GHC ticket #11587 * 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 with `hs-libraries`) to the `ghc-pkg` registration information. This naming convention follows the existing `library-dirs` and `dynamic-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). -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14182 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler