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

On Mon, Apr 8, 2013 at 1:32 AM, Luke Evans 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 /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.

To itself; that's actually the internal reference that gets compiled into the others, and as such is the actual source of the problem. (In an ELF shared object, that would be the soname. Note that it *must* be a full path on OS X, unlike Linux/ELF.) -- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

… 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 indeed the first entry in the self-identification, rather than the paths of dependent libraries. -- Luke P.S. It would be great if the HP could have more frequent patches for critical issues like this. I've no problem with 6 monthly 'feature release' updates, but there are bound to be big defects for which a 6 month cycle is a very long time. Another similar one is that I found that yesod's development server doesn't run on 7.4.2 due to a bug (allegedly long since fixed). On 2013-04-08, at 10:08 AM, Luke Evans wrote:

OK, thanks again. I'll give that a whirl.

On 2013-04-08, at 7:48 AM, Brandon Allbery wrote:

...

On Mon, Apr 8, 2013 at 1:32 AM, Luke Evans 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 /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.

To itself; that's actually the internal reference that gets compiled into the others, and as such is the actual source of the problem. (In an ELF shared object, that would be the soname. Note that it *must* be a full path on OS X, unlike Linux/ELF.)

-- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net