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

Will Song will.song at trailofbits.com
Wed Jun 3 19:15:52 UTC 2020


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.


More information about the Haskell-Cafe mailing list