Loading in ghci fails unless adding libwxc.so path to LD_LIBRARY_PATH

[phischu]

I use wx-0.92.1.0 and wxcore-0.92.1.0. Compilation works perfectly fine (thanks for your hard work), but loading my executable with cabal repl fails with the following error message:

GHCi, version 7.8.4: http://www.haskell.org/ghc/  :? for help
Loading package ghc-prim ... linking ... done.
...
Loading package process-1.2.0.0 ... linking ... done.
Loading package strict-0.3.2 ... linking ... done.
Loading package wxdirect-0.92.1.0 ... linking ... done.
Loading package wxc-0.92.1.1 ... linking ... done.
Loading package wxcore-0.92.1.0 ... <command line>: can't load .so/.DLL for: /home/pschuster/Projects/machina/.cabal-sandbox/lib/x86_64-linux-ghc-7.8.4/wxcore-0.92.1.0/libHSwxcore-0.92.1.0-ghc7.8.4.so (libwxc.so: cannot open shared object file: No such file or directory)

Starting the repl with stack repl and a different version of GHC fails for the same reason:

GHCi, version 7.10.2: http://www.haskell.org/ghc/  :? for help
<command line>: can't load .so/.DLL for: /home/pschuster/Projects/machina/.stack-work/install/x86_64-linux/lts-3.10/7.10.2/lib/x86_64-linux-ghc-7.10.2/wxcore-0.92.1.0-15lAjJPnZ9tLBMMR8v1uFQ/libHSwxcore-0.92.1.0-15lAjJPnZ9tLBMMR8v1uFQ-ghc7.10.2.so (libwxc.so: cannot open shared object file: No such file or directory)

There is a libwxc.so in .cabal-sandbox/lib/x86_64-linux-ghc-7.8.4/wxc-0.92.1.1. If I add the path to LD_LIBRARY_PATH everything works fine:

> export LD_LIBRARY_PATH=:.cabal-sandbox/lib/x86_64-linux-ghc-7.8.4/wxc-0.92.1.1
> cabal repl
...
Ok, modules loaded, ...

None of my attempts of giving the path directly to ghc, gcc or ld via --ghc-option, -optl-Wl, etc. was fruitful.

[codygman]

I'm also affected by this bug with stack using wx-0.92.2.0

[codygman]

I wonder if this commit fixes it:

https://github.com/wxHaskell/wxHaskell/commit/bdab2f530a7840b917b2b954655d99f49a7f62b2

I don't remember the syntax to build from master in stack atm, but maybe I or someone else can try later.

[ppp13]

I am experiencing the same issue in version 0.92.2.0 too. The lib directory for wxc-0.92.2.0 is missing in the rpath of libHSwxcore-0.92.2.0-ghc7.8.4.so.

patchelf --print-rpath libHSwxcore-0.92.2.0-ghc7.8.4.so

/home/x/.cabal/lib/x86_64-linux-ghc-7.8.4/wxdirect-0.92.2.0:/home/x/.cabal/lib/x86_64-linux-ghc-7.8.4/strict-0.3.2:/usr/lib64/ghc-7.8.4/process-1.2.0.0:/usr/lib64/ghc-7.8.4/split-0.2.2:/usr/lib64/ghc-7.8.4/stm-2.4.2:/usr/lib64/ghc-7.8.4/parsec-3.1.5:/usr/lib64/ghc-7.8.4/text-1.1.1.3:/usr/lib64/ghc-7.8.4/mtl-2.1.3.1:/usr/lib64/ghc-7.8.4/transformers-0.3.0.0:/usr/lib64/ghc-7.8.4/directory-1.2.1.0:/usr/lib64/ghc-7.8.4/unix-2.7.0.1:/usr/lib64/ghc-7.8.4/time-1.4.2:/usr/lib64/ghc-7.8.4/old-locale-1.0.0.6:/usr/lib64/ghc-7.8.4/filepath-1.3.0.2:/usr/lib64/ghc-7.8.4/containers-0.5.5.1:/usr/lib64/ghc-7.8.4/bytestring-0.10.4.0:/usr/lib64/ghc-7.8.4/deepseq-1.3.0.2:/usr/lib64/ghc-7.8.4/array-0.5.0.0:/usr/lib64/ghc-7.8.4/base-4.7.0.2:/usr/lib64/ghc-7.8.4/integer-gmp-0.5.1.0:/usr/lib64/ghc-7.8.4/ghc-prim-0.3.1.0:/usr/lib64/ghc-7.8.4/rts-1.0

As alternative workaround I edited it manually patchelf --set-rpath /home/x/.cabal/lib/x86_64-linux-ghc-7.8.4/wxdirect-0.92.2.0:/home/x/.cabal/lib/x86_64-linux-ghc-7.8.4/strict-0.3.2:/usr/lib64/ghc-7.8.4/process-1.2.0.0:/usr/lib64/ghc-7.8.4/split-0.2.2:/usr/lib64/ghc-7.8.4/stm-2.4.2:/usr/lib64/ghc-7.8.4/parsec-3.1.5:/usr/lib64/ghc-7.8.4/text-1.1.1.3:/usr/lib64/ghc-7.8.4/mtl-2.1.3.1:/usr/lib64/ghc-7.8.4/transformers-0.3.0.0:/usr/lib64/ghc-7.8.4/directory-1.2.1.0:/usr/lib64/ghc-7.8.4/unix-2.7.0.1:/usr/lib64/ghc-7.8.4/time-1.4.2:/usr/lib64/ghc-7.8.4/old-locale-1.0.0.6:/usr/lib64/ghc-7.8.4/filepath-1.3.0.2:/usr/lib64/ghc-7.8.4/containers-0.5.5.1:/usr/lib64/ghc-7.8.4/bytestring-0.10.4.0:/usr/lib64/ghc-7.8.4/deepseq-1.3.0.2:/usr/lib64/ghc-7.8.4/array-0.5.0.0:/usr/lib64/ghc-7.8.4/base-4.7.0.2:/usr/lib64/ghc-7.8.4/integer-gmp-0.5.1.0:/usr/lib64/ghc-7.8.4/ghc-prim-0.3.1.0:/usr/lib64/ghc-7.8.4/rts-1.0:/home/x/.cabal/lib/x86_64-linux-ghc-7.8.4/wxc-0.92.2.0 libHSwxcore-0.92.2.0-ghc7.8.4.so

[letheed]

Encountered this issue today with stack as well.

[damiencourousse]

Also encountered this issue today with stack.

[kokobd]

Still encountered this issue today with stack. Setting LD_LIBRARY_PATH works, though.