
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 2013-04-07, at 9:42 PM, Brandon Allbery
On Mon, Apr 8, 2013 at 12:10 AM, Luke Evans
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 allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net