Re: Different behavior in ghci 7.8.3 vs 7.10.1?

On the second suggestion, I tried ldd and found that the undefined symbol is flagged 'B' in the nm output (.bss section). This symbol is defined in the shared library, and the output of ghc -v2 shows that this shared library is linked without problems on startup of ghci. When the Haskell/FFI function is run the symbol is undefined. On Sat, Jun 27, 2015 at 7:26 AM, Dominick Samperi wrote:

Thank you, the 'ghci -v2' suggestion was helpful. I now see the expected link steps.

But when I try to run there are unresolved symbols (with ghci 7.10.1; everything works fine with ghci 7.8.3). This may be due to the fact that I have not installed the Haskell Platform with ghci 7.10.1 under Fedora 21. I'm using the latest released HP with ghci 7.8.3.

To test ghci 7.10.1 I compiled from source and simply placed the resulting bin in my PATH. Perhaps this is not enough?

On Sat, Jun 27, 2015 at 6:01 AM, Sergei Trofimovich wrote:

...

On Fri, 26 Jun 2015 23:05:55 -0400 Dominick Samperi wrote:

...

Hello,

I'm trying to run code that works with ghci 7.8.3 under ghci 7.10.1 but this fails.

Under 7.8.3, when I run from the shell: export LD_LIBRARY_PATH=thepath ghci -lmylib -fno-ghci-sandbox mydriver.hs

I see the usual startup diagnostics along with Loading object (dynamic) mylib ... done final link ... done [1 of 1] Compiling Main Main>

But under 7.10.1, when I do the same, there is no indication that linking happens, and when I try to run the program there are undefined references.

I probably missed the post that explains this behavior. Can somebody provide a pointer to a work-around?

There is two separate issues:

1. ghc-7.10 became less chatty when loads libraries. 'ghci -v2' gets it back with a bit of noise

2. looks more like actual problem. is your mylib fully linked against it's depends? LD_LIBRARY_PATH=/the/path ldd -u /path/to/mylib.so LD_LIBRARY_PATH=/the/path ldd /path/to/mylib.so you can also try to inspect LD_DEBUG=help ghci ...

--

Sergei