Skip to content
GitLab
Projects Groups Topics Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
  • Register
  • Sign in
  • GHC GHC
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributor statistics
    • Graph
    • Compare revisions
    • Locked files
  • Issues 5.5k
    • Issues 5.5k
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
  • Merge requests 625
    • Merge requests 625
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Artifacts
    • Schedules
    • Test cases
  • Deployments
    • Deployments
    • Releases
  • Analytics
    • Analytics
    • CI/CD
    • Code review
    • Insights
    • Issue
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • Glasgow Haskell CompilerGlasgow Haskell Compiler
  • GHCGHC
  • Issues
  • #15397
Closed
Open
Issue created Jul 16, 2018 by Ara Adkins@iamrecursionDeveloper

Linking Issue with libffi on Ubuntu and Fedora with Provided Bindists

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
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking