[GHC] #15837: Hadrian should build dynamically linked ghc binary

[GHC]

#15837: Hadrian should build dynamically linked ghc binary
-------------------------------------+-------------------------------------
        Reporter:  davide            |                Owner:  davide
            Type:  bug               |               Status:  new
        Priority:  normal            |            Milestone:
       Component:  Build System      |              Version:  8.6.1
  (Hadrian)                          |
      Resolution:                    |             Keywords:
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  None/Unknown      |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):  Phab:D5385
       Wiki Page:                    |  Phab:D5327
-------------------------------------+-------------------------------------

Comment (by davide):

 The locally built libffi is bundled with the rts package. As libffi is
 ''not'' a haskell library, the naming convention is to call the library
 `Cffi` in `rts/rts.cabal.in` (see specifically the line `extra-bundled-
 libraries: Cffi`).

 When ghc is calculating the linker options, ghc sees that `Cffi` is
 bundled with rts and tries to link with it. The "C" prefix is striped, but
 unlike haskell libraries a version number is not suffixed (this logic is
 in `compiler/main/Packages.hs:packageHsLibs`). Hence ghc links with the
 `-lffi` option instead of e.g. `-lCffi` or `-lCffi-7.0`. This means the
 linker is looking for a corresponding .so file named `libffi.so`.

 As per comment:14 it is easy to produce the `libffi.so` file, but it isn't
 in the correct location at the moment. There are 2 relevant steps that
 hadrian takes here:
 1. After building libffi, copy the .so from
 `_build/stage1/libffi/build/inst/lib/libffi.so` to
 `_build/stage1/rts/build/X`.
 2. "Install" the .so by copying it from `_build/stage1/rts/build/` to
 `_build/stage1/lib/x86_64-linux-ghc-8.7.20181205/X`
 Currently X in 1 and 2 uses a naming convention convention of e.g
 .`libCffi-ghc8.7.20181126_thr_debug.so`. This naming convention does
 **not** match ghc's as described before. It seems that changing X to match
 the ghc naming convention would solve the problem, but is that the correct
 solution? Changing the naming convention for the static libffi libraries
 also sounds necessary, but I thought the the static build been working so
 far. How is that possible?

-- 
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15837#comment:18>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler