ghc: Library not loaded: libffi.5.dylib

[ryandesign (Ryan Carsten Schmidt)]

While trying to upgrade from 6.10.1_9 to 6.10.3_1, I got a Crash Reporter dialog stating:

Link (dyld) error:

Library not loaded: /mp/lib/libffi.5.dylib
  Referenced from: /mp/lib/ghc-6.10.1/hsc2hs
  Reason: image not found

/mp is my MacPorts prefix.

This error shows two problems:

1. The new version of ghc is trying to use parts from the currently-installed version of ghc to build itself. This means the software might build differently for users who had a previous version installed vs. those who didn't. This is bad and a port should probably never use an installed version of itself to build a new version of itself.
2. hsc2hs was linked with libffi but ghc did not declare a dependency on libffi. Either ghc needs to declare a dependency on libffi, or ghc needs to not link with libffi even if it is installed.

[ryandesign (Ryan Carsten Schmidt)]

I was able to work around this by deactivating the old ghc before trying to install the new ghc, but ghc should be fixed so this is not necessary.

[gwright@…]

My hsc2hs doesn't depend on libffi (checked by otool -L). I'm guessing that this is related to ghc's internal cabal used during the build. It ignores the top level environment variables and options and goes rooting around the file system for whatever tools it thinks should be used. Because it ignores the environment variables we can set in the portfile, the only fix is to patch in the correct options. Ugh. But it needs to be done....

[gwright@…]

OK, this is indeed a cabal problem. GHC includes a copy of the libffi source, from which it builds an archive (libffi.a) this should be statically linked to the binaries produced at the end of the build. However, if another libffi is present (e.g., /opt/local/lib/libffi.dylib), it seems to get linked in first.

Can be fixed, but not pretty.

[gwright@…]

r53745 should fix this. Turns out not to be a cabal problem, but one in core ghc. A private copy of libffi is built and is expected to be linked in as part of the runtime. However, the only thing which ensures that this library is used is a bit of light search path hackery.

The portfile has been changed to implement the correct solution: call the private version of libffi something different (libHsLocalFfi) to prevent the name clash.