stack doesn't find a shared object/dynamic library

[dtaskoff]

(a similar scenario: #1974)
I'm building a project using wxHaskell with wx, wxc, wxcore and wxdirect as extra-deps in my stack.yaml.
The project builds fine on Linux and Windows and stack exec works right on Linux, however,
on Windows it's complaining about a missing wxc.dll: The program can't start because wxc.dll is missing from your computer. stack ghci fails on both Linux and Windows,
with the same message on Windows and the following error on Linux:

<command line>: can't load .so/.DLL for: .../lib/x86_64-linux-ghc-7.10.3/wxcore-0.92.2.0-FbIxJ6t4QQeCNL8GzPaZRM/libHSwxcore-0.92.2.0-FbIxJ6t4QQeCNL8GzPaZRM-ghc7.10.3.so (libwxc.so: cannot open shared object file: No such file or directory)

On both systems, the .so/.dll was present, located at .stack-work/install/x86_64-linux/../lib/x86_64-linux-ghc-7.10.3/wxc-0.92.2.0-.. and when I copied them to the current directory, where the command is called, everything went smoothly.
I would expect stack to handle those cases.

(Note: the solution mentioned in #467 doesn't work)

[dtaskoff]

Any progress on this one?
Still happening with the latest Stack.

[stla]

See here how I did with cabal, if this could help: https://stackoverflow.com/a/44228347/1100107

However I'm not able to install wxc with stack on Windows. How did you do that ?

[dtaskoff]

Thank you @stla, that's exactly the workaround I'm currently using.
About using wxhaskell with stack:

• add the following to your stack.yaml:

extra-deps:
- wx-0.92.3.0
- wxc-0.92.3.0
- wxcore-0.92.3.0
- wxdirect-0.92.3.0

Now running stack build --extra-include-dirs=%wxInclude% --extra-include-dirs=%mswuInclude% --extra-lib-dirs=%wxLib% should succeed, where if you built wxwidgets in the directory wx:

• wxInclude is wx/include
• mswuInclude is wx/lib/gcc_dll/mswu
• wxLib is wx/lib

I'd be glad to further assist if needed.

[stla]

Thank you @leohaskell
I missed %mswuInclude%. Now my project works with stack, very nice.

I also include the DLLs folder in --extra-lib-dirs for my project, otherwise there are some error messages during the built.

[shadowcomer]

I also just ran into this problem, but on Linux. Building the project is worked fine, but I noticed my intero failed to load for no apparent reason. Upon launching 'stack ghci', it fails with the same reason: it can't find libwxc.so.

What I did to get it working was update extra-lib-dirs, with the path to the library in the .stack-work directory, for the project's stack.yaml, similarly to what @leohaskell proposed.

However, it requires using a global path, which would break sharing the package, and also the library path contains what appears to be a hash (wxc-0.92.3.0-7rSQ2...i1eo4), which I imagine can change and would break again.

Shouldn't stack be automatically finding the library and include directories for each package and automatically including it? It seems reasonable even if the package is not on stackage (as is the case for wxc), given that it's downloaded to a path within .stack-work from hackage.

[mgsloan]

However, it requires using a global path, which would break sharing the package, and also the library path contains what appears to be a hash (wxc-0.92.3.0-7rSQ2...i1eo4), which I imagine can change and would break again.

You can add it to your ~/.stack/config.yaml

Shouldn't stack be automatically finding the library and include directories for each package and automatically including it?

How will it know where to look if you don't tell it?

[shadowcomer]

You can add it to your ~/.stack/config.yaml
Wouldn't this still have the problem of the hash part of the path? I'm not really sure about this, I'm just saying because it looks like a hash.

Also, isn't it generally not good to add local configuration to generally applicable configuration?

How will it know where to look if you don't tell it?
Given that stack manages the package all by itself (the package was added to extra-deps), finding it on hackage, downloading it, building it, and finally installing it, doesn't that mean it knows where it has placed its output?

I now noticed that there are some libHSwx, libHSwxcore... libraries (also hashed?) where the wxc base package path is. Maybe wxc is placing libwxc in a non-standard way inside the wrong path?

This is an example of the structure:

• .stack-work/install/x86_64-linux-nopie/lts-9.10/8.0.2/lib/libHSwx-0.92.3.0-KU6F...T55hz-ghc8.0.2.so
• .stack-work/install/x86_64-linux-nopie/lts-9.10/8.0.2/lib/wxc-0.92.3.0-7rSQ...1eo4/libwxc.so

It looks like it is using libHSwx and can locate it, but it couldn't locate libwxc.so.

Thank you for your time.

[dtaskoff]

I think that this issue is for closing, since it's not an issue with stack, but with wxc. If you look at their Setup.hs, you'll see that they're building/linking libwxc manually, so in order for stack to find it, wxc's postCopy hook should be modified.

[shadowcomer]

Ah, I see. Thanks everyone!

[typesanitizer]

(Total newbie here, please feel free to correct me.)

I didn't understand all the points being made but one thing that worked for me:

• Used the usual stack build to build.
• I just copied the two files (libwxc.so -- this appears to be a relative symlink -- and libwxc.so.0.92.3.0) from the folder .stack-work/install/x86_64-linux-nopie/lts-9.10/8.0.2/lib/wxc-0.92.3.0-7rSQ...1eo4 to one level up, at the same place as the libHSwx-0.92.3.0-KU6F...T55hz-ghc8.0.2.so file. This makes Intero work fine for me.

@leohaskell -- just to make sure I'm understanding this properly -- are you suggesting that this move/copy step (that I'm doing manually) is actually something that is wxc's responsibility (and not Stack's), so one should modify their Setup.hs file by adding a postCopy hook so that everything just works?

[dtaskoff]

@theindigamer, yes, I meant exactly that : )
Another options is to just modify this line of their Setup.hs.

[unclechu]

I'm too having this issue:

$ (env HOME='/home/unclechu/Storage/unclechu-lts-9.x' PATH='/usr/local/bin:/usr/bin' stack build --install-ghc)
midihaskey-0.1.0.0: unregistering (local file changes: ChangeLog.md README.md app/Main.hs midihaskey.cabal package.yaml src/Keys.hs src/Utils.hs)
midihaskey-0.1.0.0: configure (lib + exe)
Configuring midihaskey-0.1.0.0...
midihaskey-0.1.0.0: build (lib + exe)
Preprocessing library midihaskey-0.1.0.0...
[1 of 2] Compiling Utils            ( src/Utils.hs, .stack-work/dist/x86_64-linux/Cabal-1.24.2.0/build/Utils.o )
[2 of 2] Compiling Keys             ( src/Keys.hs, .stack-work/dist/x86_64-linux/Cabal-1.24.2.0/build/Keys.o )
<command line>: can't load .so/.DLL for: /home/unclechu/dev/haskell/midihaskey/.stack-work/install/x86_64-linux/lts-9.21/8.0.2/lib/x86_64-linux-ghc-8.0.2/libHSwxcore-0.92.3.0-7crw4DOSyVYLnCcwhdBKS4-ghc8.0.2.so (libwxc.so: cannot open shared object file: No such file or directory)

--  While building package midihaskey-0.1.0.0 using:
      /home/unclechu/Storage/unclechu-lts-9.x/.stack/setup-exe-cache/x86_64-linux/Cabal-simple_mPHDZzAJ_1.24.2.0_ghc-8.0.2 --builddir=.stack-work/dist/x86_64-linux/Cabal-1.24.2.0 build lib:midihaskey exe:midihaskey --ghc-options " -ddump-hi -ddump-to-file"
    Process exited with code: ExitFailure 1

My stack.yaml file:

resolver: lts-9.21
system-ghc: false
packages:
  - .
extra-deps:
  - wx-0.92.3.0
  - wxc-0.92.3.0
  - wxcore-0.92.3.0
  - wxdirect-0.92.3.0

[unclechu]

As a hack for now I use this environment variable:

LD_PRELOAD="`pwd`/.stack-work/install/x86_64-linux/lts-9.21/8.0.2/lib/x86_64-linux-ghc-8.0.2/wxc-0.92.3.0-7rSQ2frk0nJK7cSQ3i1eo4/libwxc.so"

[shadowcomer]

@unclechu That solution looks like a great compromise, given then circumstances.

Thanks for your input!

[unclechu]

@shadowcomer I actually created a little more flexible hack as env.sh:

#!/usr/bin/env bash
# FIXME This is hack for https://github.com/commercialhaskell/stack/issues/2299
set -e
PFX=$(dirname -- "`stack path --local-pkg-db`")
LIBWXC=$(ls -- $PFX/lib/*-ghc-*/wxc-*/libwxc.so)||true
[[ -n $LIBWXC ]] && env "LD_PRELOAD=$LIBWXC" "$@" || "$@"

To use it this way ./env.sh stack build.

[typesanitizer]

I got a PR merged upstream with a change for Linux so this should be fixed in the next release -- it'd be awesome if people could test if stack ghci works for them, say using the test repository here. I wasn't sure about the Windows fix but it would be useful if someone else could submit a patch upstream for it.