[GHC] #14182: Allow full control over dyn lib names

[GHC]

#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