On Mon, Apr 8, 2013 at 1:32 AM, Luke Evans l...@eversosoft.com wrote:
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
OK, thanks again. I'll give that a whirl.
On 2013-04-08, at 7:48 AM, Brandon Allbery allber...@gmail.com wrote:
On Mon, Apr 8, 2013 at 1:32 AM, Luke Evans l...@eversosoft.com wrote:
Unfortunately, it looks like
… and this works just fine. \o/
At least cabal now installs/builds the llvm 3.0.1.0 package successfully. So,
normality has been restored… any remaining problems are therefore my own :-)
That last reference has to be changed with the install_name_tool -id option
(rather than -change) as
I'm trying to get LLVM 3.0 installed and then have the llvm-3.0.1.0 package
install and bind against it with cabal.
I'm on a recent 64 bit Mac which shows up in various messages like: Target
platform inferred as: x86_64-apple-darwin
I was advised on the Haskell IRC channel to install a 3.0
Ah, I see GHC bug #5982, which smells awfully similar.
The bug suggests a fix along the lines of:
install_name_tool /usr/local/lib/ghc-7.4.1/libHSrts-ghc7.4.1.dylib -change
/Users/ian/zz64/ghc-7.4.1/libffi/build/inst/lib/libffi.5.dylib
/usr/local/lib/ghc-7.4.1/libffi.dylib
Presumably this is
On Mon, Apr 8, 2013 at 12:10 AM, Luke Evans l...@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
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:
