Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Stack supplied GHC links against wrong dylibs on OSX #1826

Closed
tinco opened this issue Feb 22, 2016 · 5 comments
Closed

Stack supplied GHC links against wrong dylibs on OSX #1826

tinco opened this issue Feb 22, 2016 · 5 comments

Comments

@tinco
Copy link

tinco commented Feb 22, 2016

When I build the package LLVM.General.AST with lts-5.4 on OSX I get the following error:

    Preprocessing library llvm-general-3.5.1.2...
    dyld: Library not loaded: @rpath/libffi.dylib
      Referenced from: /private/var/folders/2k/lfhsrv497ybbp6b1hv4y7_680000gn/T/stack13607/llvm-general-3.5.1.2/.stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/LLVM/General/Internal/LibraryFunction_hsc_make
      Reason: Incompatible library version: LibraryFunction_hsc_make requires version 7.0.0 or later, but libffi.dylib provides version 1.0.0

I have two versions installed:

$ find /usr -name "libffi.dylib" | xargs otool -L
/usr/lib/libffi.dylib:
    /usr/lib/libffi.dylib (compatibility version 1.0.0, current version 1.0.0)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1213.0.0)
/usr/local/Cellar/libffi/3.0.13/lib/libffi.dylib:
    /usr/local/opt/libffi/lib/libffi.6.dylib (compatibility version 7.0.0, current version 7.1.0)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1213.0.0)

The second one is the one we need, this is the one homebrew installed. Stack itself was installed with homebrew as well. LLVM 3.5 was also installed using homebrew. Since lts 5.4 (for me) stack is supplying its own ghc which I think is the root of the issue.

It could be a problem of homebrew or llvm.general as well of course, though I am suspecting stack might fix this by setting $LD_LIBRARY_PATH or something, I'm not really a homebrew expert.

@borsboom
Copy link
Contributor

Stack installs GHC using the official binary distribution downloaded from https://www.haskell.org/ghc/download_ghc_7_10_3#macosx_x86_64, which won't have any extra knowledge about Homebrew-installed libraries. The DYLD_LIBRARY_PATH environment variable can be used tell the dynamic linker where to look for them, but unfortunately it is ignored by GHC on Mac OS 10.11 (El Capitan) without a workaround.

@borsboom borsboom added this to the Support milestone Feb 22, 2016
@samvher
Copy link

samvher commented Apr 23, 2016

I had the same problem and solved it by passing an extra-lib-dirs parameter to stack. I installed all my dependencies with MacPorts, so my libraries are in /opt/local/lib, I added the following to my ~/.stack/config.yaml :

extra-lib-dirs:
- /opt/local/lib/

I imagine that if you're installing llvm-general locally for your package you can also add the setting to your project.cabal file.

@zjhmale
Copy link

zjhmale commented May 30, 2016

@tinco i got the same problem and inspired by @samvher , i solve it adding an explicit absolute path to the libffi.dylib in stack.yaml

extra-lib-dirs: [/usr/local/Cellar/libffi/3.0.13/lib]

but this solution is hard coded and maybe will encounter the same issue when building the project in other place e.g. travis-ci etc.

@borsboom
Copy link
Contributor

In OS X El Capitan, DYLD_LIBRARY_PATH doesn't get passed to GHC anymore due to System Integrity Protection. There's not a lot we can do about it, so I'm not sure if this issue can be addressed. Best to just add the extra-lib-dirs in your ~/.stack/config.yaml.

@zjhmale
Copy link

zjhmale commented Aug 13, 2016

@borsboom excellent! thx for mention this way.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants