#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