error while loading shared libraries: librust_exp.so about rust-exp

[blitzcode]

Oh, I guess the install name makes it find the library on OS X, but no such thing on Linux. I assume it works if you add target/release/ to your DYLD_LIBRARY_PATH? Could you try adding -optl-Wl,-rpath,'$ORIGIN/target/release' to the ghc-options field in rust-exp.cabal? I'm not completely sure, the path might need to be './target/release'. Thanks ;-)

[Johnson-A]

I tried both '$ORIGIN/target/release' and './target/release' but I'm getting the same error after calling make again. I'm not familiar with ghc options but I'd really like to try your n-body simulation! I'm rewriting a barnes hut implementation in rust and was wondering how efficient your implementation was!

[blitzcode]

GHC just uses the system linker here, so this is unlikely to be GHC specific. We'd be in he same situation trying to link two pieces of C code together. Same solutions / troubleshooting steps apply!

How do you run the executable, just stack exec rust-exp?

You could try these steps:

• Set the rpath to am absolute path, i.e. ~/dev/rust-exp/target/release/
• Run with LD_LIBRARY_PATH=~/dev/rust-exp/target/release/ stack exec rust-exp
• Copy the DSO into the stack build directory (i.e. ~/dev/rust-exp/.stack-work/install/x86_64-linux/lts-5.4/7.10.3/bin/)
• Build the rust library as a static library (don't forget to make clean)

Do any of the above work for you? I'd of course be interested in fixing this properly so other Linux users don't have to jump through any hoops.

[Johnson-A]

I had been running the executable with stack exec rust-exp, and even with the full path in ghc-options I got the same error. The good news is that when I run LD_LIBRARY_PATH=~/dev/rust-exp/target/release/ stack exec rust-exp everything works! Really impressive work by the way! Let me include my rust-exp.cabal (renamed to .txt to satisfy github)
rust-exp.txt

[blitzcode]

Great to hear you got it running and found some utility in it ;-)

Bummer about the rpath, though. Would've been nice to commit something that fixes it without having to tell people to mess with their environment variables. Could you try if changing dylib to staticlib in the Cargo.toml also works for you? The only reason I use dynamic linking is to speed up the development process. No need to always re-link the Haskell executable when >90% of the time I only touch the Rust code. If you can confirm this works for you, I'll just just switch to static linking by default.

[Johnson-A]

Switching to staticlib worked as well. I open a pull request if you want to add the changes! Thanks

[blitzcode]

Great, thanks! I'll have a look at the rpath thing at some point...