[Haskell-cafe] GHC trying to load dynamic library when it really shouldn't

[Jinwoo Lee]

Does your code use TemplateHaskell? In that case, the compiler will try to
load the library for the compile-time computation.


On Wed, Jun 3, 2020 at 12:17 PM Will Song via Haskell-Cafe <
haskell-cafe at haskell.org> wrote:

> Hey all, I am experiencing some weird build issues with respect to GHC. I
> would like to mention that what I am doing is somewhat non-standard but
> theoretically I think it should work.
>
> I am developing a Haskell program which depends on a library, hevm, with
> several external library dependencies, libsecp256k1 and libff. Since these
> libraries are a bit of a pain to install by default in the macOS ecosystem,
> having no brew packages, my plan is to statically link these libraries into
> the release builds. To start off this task, I have simply moved the dynamic
> libraries for secp256k1 to another location, e.g. # mv
> /usr/local/lib/libsecp256k1.dylib{,.bak}. Rebuilding the dependency hevm
> appears to work as expected. It compiles fine, and otool reports the
> following.
>
> % otool -L .stack-work/install/x86_64-osx/lts-14.14/8.6.5/bin/hevm
> .stack-work/install/x86_64-osx/lts-14.14/8.6.5/bin/hevm:
>         /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
> version 1281.0.0)
>         libff.dylib (compatibility version 0.0.0, current version 0.0.0)
>         /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current
> version 800.7.0)
>         /usr/lib/libz.1.dylib (compatibility version 1.0.0, current
> version 1.2.11)
>         /usr/lib/libncurses.5.4.dylib (compatibility version 5.4.0,
> current version 5.4.0)
>         /usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current
> version 7.0.0)
>         /usr/lib/libcharset.1.dylib (compatibility version 2.0.0, current
> version 2.0.0)
>
> We can check libHShevm... as well and it does not depend on the secp256k1
> dylib anymore.
>
> However, moving back onto my program, the build fails.
>
> % stack build
> Building all executables for `echidna' once. After a successful build of
> all of them, only specified executables will be rebuilt.
> echidna-1.5.0: configure (lib + exe)
> Configuring echidna-1.5.0...
> Warning: 'ghc-options: -threaded' has no effect for libraries. It should
> only
> be used for executables.
> echidna-1.5.0: build (lib + exe)
> Preprocessing library for echidna-1.5.0..
> Building library for echidna-1.5.0..
> [ 1 of 24] Compiling Echidna.Mutator  ( lib/Echidna/Mutator.hs,
> .stack-work/dist/x86_64-osx/Cabal-2.4.0.1/build/Echidna/Mutator.o )
> [ 2 of 24] Compiling Echidna.Orphans.JSON ( lib/Echidna/Orphans/JSON.hs,
> .stack-work/dist/x86_64-osx/Cabal-2.4.0.1/build/Echidna/Orphans/JSON.o )
> <command line>: can't load .so/.DLL for: libsecp256k1.dylib
> (dlopen(libsecp256k1.dylib, 5): image not found)
>
> --  While building package echidna-1.5.0 using:
>
> /Users/incertia/.stack/setup-exe-cache/x86_64-osx/Cabal-simple_mPHDZzAJ_2.4.0.1_ghc-8.6.5
> --builddir=.stack-work/dist/x86_64-osx/Cabal-2.4.0.1 build lib:echidna
> exe:echidna-test --ghc-options " -ddump-hi -ddump-to-file
> -fdiagnostics-color=always"
>   Process exited with code: ExitFailure 1
>
> Would anyone happen to know why this failure is occurring? We have no C
> sources that would create unresolved references to this library, all the
> code is Haskell. My understanding is that ghc should end up using the
> static variant now that there is no dynamic library but clearly this
> intuition is misguided.
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20200604/63323f49/attachment.html>