-
Notifications
You must be signed in to change notification settings - Fork 843
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
stack doesn't find a shared object/dynamic library #2299
Comments
Any progress on this one? |
See here how I did with cabal, if this could help: https://stackoverflow.com/a/44228347/1100107 However I'm not able to install |
Thank you @stla, that's exactly the workaround I'm currently using.
extra-deps:
- wx-0.92.3.0
- wxc-0.92.3.0
- wxcore-0.92.3.0
- wxdirect-0.92.3.0 Now running
I'd be glad to further assist if needed. |
Thank you @leohaskell I also include the |
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. |
You can add it to your
How will it know where to look if you don't tell it? |
Also, isn't it generally not good to add local configuration to generally applicable configuration?
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:
It looks like it is using libHSwx and can locate it, but it couldn't locate libwxc.so. Thank you for your time. |
I think that this issue is for closing, since it's not an issue with stack, but with |
Ah, I see. Thanks everyone! |
(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:
@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 |
@theindigamer, yes, I meant exactly that : ) |
I'm too having this issue:
My 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 |
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" |
@unclechu That solution looks like a great compromise, given then circumstances. Thanks for your input! |
@shadowcomer I actually created a little more flexible hack as #!/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 |
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 |
(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:
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)
The text was updated successfully, but these errors were encountered: