Thanks Brandon.
I've patched:
/Library/Frameworks/GHC.framework/Versions/7.4.2-x86_64/usr/lib/ghc-7.4.2/libHSrts-ghc7.4.2.dylib
and
/Library/Frameworks/GHC.framework/Versions/7.4.2-x86_64/usr/lib/ghc-7.4.2/ibHSrts_thr-ghc7.4.2.dylib
both pointing to:
/Library/Frameworks/GHC.framework/Versions/7.4.2-x86_64/usr/lib/ghc-7.4.2/libffi.dylib
Unfortunately, it looks like
/Library/Frameworks/GHC.framework/Versions/7.4.2-x86_64/usr/lib/ghc-7.4.2/libffi.dylib
is pointing to the dodgy library too, e.g.:
> otool -L /Library/Frameworks/GHC.framework/Versions/7.4.2-x86_64/usr/lib/ghc-7.4.2/libffi.dylib
/Users/ian/zz64/ghc-7.4.2/libffi/build/inst/lib/libffi.5.dylib (compatibility version 6.0.0, current version 6.10.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 159.1.0)
Not sure what to patch the first reference in that one to.
On Mon, Apr 8, 2013 at 12:10 AM, Luke Evans
<luke@eversosoft.com> wrote:
Unfortunately, it looks like my cabal build failure occurs in a temporary and very short-lived directory. So presumably the dodgy FFI gets copied into there from elsewhere. I wonder if I can find the source...
It's running an executable it seems to have built to generate something else for the build, so I suspect you are in fact seeing the ghc bug and you should fix the ghc reference. If you installed the official HP package, you need to find libHSrts-ghc7.4.2.dylib somewhere under /Library/Haskell and use install_name_tool on that.
--
brandon s allbery kf8nh sine nomine associates