<div dir="ltr"><div>Does your code use TemplateHaskell? In that case, the compiler will try to load the library for the compile-time computation.</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jun 3, 2020 at 12:17 PM Will Song via Haskell-Cafe <<a href="mailto:haskell-cafe@haskell.org">haskell-cafe@haskell.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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.<br>
<br>
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.<br>
<br>
% otool -L .stack-work/install/x86_64-osx/lts-14.14/8.6.5/bin/hevm<br>
.stack-work/install/x86_64-osx/lts-14.14/8.6.5/bin/hevm:<br>
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1281.0.0)<br>
        libff.dylib (compatibility version 0.0.0, current version 0.0.0)<br>
        /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 800.7.0)<br>
        /usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.11)<br>
        /usr/lib/libncurses.5.4.dylib (compatibility version 5.4.0, current version 5.4.0)<br>
        /usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0)<br>
        /usr/lib/libcharset.1.dylib (compatibility version 2.0.0, current version 2.0.0)<br>
<br>
We can check libHShevm... as well and it does not depend on the secp256k1 dylib anymore.<br>
<br>
However, moving back onto my program, the build fails.<br>
<br>
% stack build<br>
Building all executables for `echidna' once. After a successful build of all of them, only specified executables will be rebuilt.<br>
echidna-1.5.0: configure (lib + exe)<br>
Configuring echidna-1.5.0...<br>
Warning: 'ghc-options: -threaded' has no effect for libraries. It should only<br>
be used for executables.<br>
echidna-1.5.0: build (lib + exe)<br>
Preprocessing library for echidna-1.5.0..<br>
Building library for echidna-1.5.0..<br>
[ 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 )<br>
[ 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 )<br>
<command line>: can't load .so/.DLL for: libsecp256k1.dylib (dlopen(libsecp256k1.dylib, 5): image not found)<br>
<br>
--  While building package echidna-1.5.0 using:<br>
    /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"<br>
  Process exited with code: ExitFailure 1<br>
<br>
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.<br>
_______________________________________________<br>
Haskell-Cafe mailing list<br>
To (un)subscribe, modify options or view archives go to:<br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br>
Only members subscribed via the mailman list are allowed to post.</blockquote></div>