#15397: Linking Issue on Ubuntu and Fedora with Provided Bindists (GHC-8.4.2) -------------------------------------+------------------------------------- Reporter: _recursion | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.4 Component: Compiler | Version: 8.4.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- It appears that the bindists being given to both ubuntu and fedora users are subtly broken. When attempting to link a binary depending on libffi, the linker picks up the copy of `libffi.so.7` found in the rts folder of the distribution. This means that at runtime, despite the systems in question having a copy of `libffi.so.6`, the binary can't find the correct shared library to link against. This does not happen on Arch Linux or Gentoo, as `/usr/lib` or `/usr/lib64` are included in their linker invocations respectively, allowing the linker to pick up the correct version of the dependency. You can reproduce the issue quickly by cloning [https://github.com/luna /luna-core Luna Core] and executing the following commands. I suggest doing this on an Ubuntu or Fedora system as I know it fails on those two distros. {{{ stack build luna-shell --fast stack exec luna }}} You should see something along the lines of the following. {{{ error while loading shared libraries: libffi.so.7: cannot open shared object file: No such file or directory }}} In essence, the reproduction steps are as follows: 1. Create a project depending on libffi using ghc-8.4.2 2. Build the project 3. Execute it The ''expected'' result is that the binary links against the system copy of `libffi.so.6`, rather than the `libffi.so.7` provided in the ghc distribution. I can't guarantee that Ubuntu and Fedora are the only affected systems, but I know that Arch Linux and Gentoo were both fine with the provided bindists. All tested systems were x64, so I cannot confirm if the issue affects x86 bindists. The actual symptom appears to be a result of the linker never being given the path to the system library directory (e.g. `/usr/lib` or `/usr/lib64`), whereas on Arch and Gentoo, the linkline does contain that directory. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/15397 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler