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

[Will Song]

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 at 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 at haskell.org <mailto:haskell-cafe at 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 at 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 at haskell.org <mailto:haskell-cafe at haskell.org> <mailto:haskell-cafe at haskell.org <mailto: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 <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 at gmail.com <mailto:allbery.b at gmail.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20200604/3a9f483e/attachment.html>