Luke Evans | 8 Apr 05:39 2013

llvm-3.0.1.0 installation on Mac

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 LLVM from a location like MacPorts first, then point
cabal at the location where LLVM was installed with the appropriate config option.
So, I did a "sudo ./port install llvm-3.0", and everything seemed to proceed fine.

Then I did:
cabal install llvm --configure-option=--with-llvm-prefix=/opt/local/libexec/llvm-3.0

This looks promising (compared to missing the config option), but eventually this happens:

Building llvm-base-3.0.1.0...
Preprocessing library llvm-base-3.0.1.0...
dyld: Library not loaded: /Users/ian/zz64/ghc-7.4.2/libffi/build/inst/lib/libffi.5.dylib
 Referenced from: /private/var/folders/tz/vlbc03q5333897z201hkmcb40000gn/T/llvm-base-3.0.1.0-3941/llvm-base-3.0.1.0/dist/build/LLVM/FFI/Analysis_hsc_make
 Reason: image not found
running dist/build/LLVM/FFI/Analysis_hsc_make failed (exit code 5)
command was: dist/build/LLVM/FFI/Analysis_hsc_make  >dist/build/LLVM/FFI/Analysis.hs
Failed to install llvm-base-3.0.1.0

I have no idea where "/Users/ian/..." is coming from!

My cabal-fu is extremely weak, so I'll plug on and see if I can figure out how cabal's analysis/build might be
going wrong here.
I'd be very grateful for any clues though!

-- Luke
(Continue reading)

Luke Evans | 8 Apr 06:10 2013

Re: llvm-3.0.1.0 installation on Mac

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 still an issue in the 7.4.2 build I have installed from Haskell Platform.

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...

On 2013-04-07, at 8:39 PM, Luke Evans <luke <at> eversosoft.com> wrote:

> 
> My cabal-fu is extremely weak, so I'll plug on and see if I can figure out how cabal's analysis/build might
be going wrong here.
> I'd be very grateful for any clues though!
> 
> -- Luke
> 
> 
Brandon Allbery | 8 Apr 06:42 2013
Picon

Re: llvm-3.0.1.0 installation on Mac

On Mon, Apr 8, 2013 at 12:10 AM, Luke Evans <luke <at> 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
allbery.b <at> gmail.com                                  ballbery <at> sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Luke Evans | 8 Apr 07:32 2013

Re: llvm-3.0.1.0 installation on Mac

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 <allbery.b <at> gmail.com> wrote:

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

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Brandon Allbery | 8 Apr 16:48 2013
Picon

Re: llvm-3.0.1.0 installation on Mac

On Mon, Apr 8, 2013 at 1:32 AM, Luke Evans <luke <at> 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 /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 <at> gmail.com                                  ballbery <at> sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Luke Evans | 8 Apr 19:08 2013

Re: llvm-3.0.1.0 installation on Mac

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

On 2013-04-08, at 7:48 AM, Brandon Allbery <allbery.b <at> gmail.com> wrote:

On Mon, Apr 8, 2013 at 1:32 AM, Luke Evans <luke <at> 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 /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 <at> gmail.com                                  ballbery <at> sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Luke Evans | 8 Apr 22:57 2013

Re: llvm-3.0.1.0 installation on Mac [RESOLVED]

… 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 <luke <at> eversosoft.com> wrote:

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

On 2013-04-08, at 7:48 AM, Brandon Allbery <allbery.b <at> gmail.com> wrote:

On Mon, Apr 8, 2013 at 1:32 AM, Luke Evans <luke <at> 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 /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 <at> gmail.com                                  ballbery <at> sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net


_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Gmane