GitLab

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 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.

Trac metadata

Trac field	Value
Version	8.4.2
Type	Bug
TypeOfFailure	OtherFailure
Priority	normal
Resolution	Unresolved
Component	Compiler
Test case
Differential revisions
BlockedBy
Related
Blocking
CC
Operating system
Architecture