The 2nd module to compile uses TemplateHaskell and that's where stack build will fail. However, trying to load Echidna.Mutator into ghci will also fail for the same reason, but it compiles just fine. The import list is pasted below. {-# LANGUAGE FlexibleContexts #-} module Echidna.Mutator where import Control.Monad.Random.Strict (fromList, MonadRandom, getRandomR) import Data.Maybe (maybe) import qualified Data.ListLike as LL

On Jun 4, 2020, at 1:51 PM, Jinwoo Lee wrote:

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 mailto:haskell-cafe@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 http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.