Is the shared library of the dependency that has it statically linked in not enough? At this point I am also unsure how ghc is able to determine which library to dynamically load.

On Jun 4, 2020, at 2:03 PM, Brandon Allbery wrote:

ghci loads dynamically for the same reason TH does: you would otherwise need a ghc linked against your static library. (You could try -fobject-code and/or an explicit -l option for the library with ghci.)

On 6/4/20, Will Song via Haskell-Cafe mailto:haskell-cafe@haskell.org> wrote:

...

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

-- brandon s allbery kf8nh allbery.b@gmail.com mailto:allbery.b@gmail.com