Different behavior in ghci 7.8.3 vs 7.10.1?

[Dominick Samperi]

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 <djsamperi at gmail.com> 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 <djsamperi at gmail.com> 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 <slyich at gmail.com> wrote:
>>> On Sat, 27 Jun 2015 07:59:33 -0400
>>> Dominick Samperi <djsamperi at gmail.com> 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