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 <allbery.b@gmail.com> 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 <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 <jinwoo68@gmail.com> 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
<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>
Only members subscribed via the mailman list are allowed to post.




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