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

On Sat, 27 Jun 2015 07:59:33 -0400 Dominick Samperi wrote:

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

Sounds right. What does 'ghc --info' show?

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.

Can you craft a complete small example with a build script that shows the error? -- Sergei

In case this is not obvious, I should also note that this is a ghci problem. When compiled using ghc 7.10.1 there are no probelms with unresolved references. On Sat, Jun 27, 2015 at 9:07 AM, Dominick Samperi wrote:

I've attached the output of ghc --info. Will have to work on crafting a small example...

On Sat, Jun 27, 2015 at 8:16 AM, Sergei Trofimovich wrote:

...

On Sat, 27 Jun 2015 07:59:33 -0400 Dominick Samperi wrote:

...

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

Sounds right. What does 'ghc --info' show?

...

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.

Can you craft a complete small example with a build script that shows the error?

--

Sergei

It turns out the problem was due to a very old Setup.hs that I was working with. After replacing it with the version recommended by the latest cabal docs the undefined reference issues disappeared. Sorry! I also added 'buildable: True' to the buildinfo file, following the latest docs. On Sat, Jun 27, 2015 at 2:53 PM, Dominick Samperi wrote:

After much trial-and-error and web searching I found a work-around for ghci 7.10.1.

It appears that BOTH extra-libraries and extra-lib-dirs must be specified in the cabal file. Previously the link parameters were specified using a <pkgname>.buildinfo file. It appears that with ghci 7.10.1 this information is no longer used? Specifically, the ld-options setting in that file is ignored.

This work-around is not satisfactory because I do not want to hard-code the path to the exra lib in the cabal file for obvious reasons.

It appears that some changes were made recently to the way cabal handles external linkage, and this is probably related to the problems reported here.

On Sat, Jun 27, 2015 at 9:18 AM, Dominick Samperi wrote:

...

In case this is not obvious, I should also note that this is a ghci problem. When compiled using ghc 7.10.1 there are no probelms with unresolved references.

On Sat, Jun 27, 2015 at 9:07 AM, Dominick Samperi wrote:

...

I've attached the output of ghc --info. Will have to work on crafting a small example...

On Sat, Jun 27, 2015 at 8:16 AM, Sergei Trofimovich wrote:

...

On Sat, 27 Jun 2015 07:59:33 -0400 Dominick Samperi wrote:

...

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

Sounds right. What does 'ghc --info' show?

...

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.

Can you craft a complete small example with a build script that shows the error?

--

Sergei