Loading package integer-gmp ... <command line>: can't load .so/.DLL for: libgmp.so (libgmp.so: cannot open shared object file: No such file or directory)

[Mateusz Kowalczyk]

On 05/12/2014 05:34 PM, Mateusz Kowalczyk wrote:
> On 05/12/2014 09:51 AM, Mateusz Kowalczyk wrote:
>> On 05/12/2014 12:41 AM, Gergely Risko wrote:> The following message is a
>> courtesy copy of an article
>>> that has been posted to gmane.comp.lang.haskell.ghc.devel as well.
>>>
>>> On Sun, 11 May 2014 21:42:45 +0200, Mateusz Kowalczyk
>> <fuuzetsu at fuuzetsu.co.uk> writes:
>>>
>>>> Are there any downsides to doing this except slightly bigger binary size?
>>>
>>> There are license issues if you want to distribute the resulting stuff.
>>> Have to ask your lawyers about lgpl + gmp + shipping binary only stuff.
>>> On the technical side, there are no other downsides.
>>>
>>>> Sorry, you're correct, I did not pass interactive. Find attached the
>>>> strace with --interactive.
>>>>
>>>> [...]
>>>>
>>>> Actually, I'm doing this already:
>>>>
>> https://github.com/Fuuzetsu/nix-project-defaults/blob/master/ghc/default.nix
>>>
>>> At the end of your strace, I see this:
>>> Loading package integer-gmp ... [pid 10676]
>>> [...]
>>>
>>> So you can see that it tries to read libgmp from a lot of places, but
>>> not from the one you specified in build.mk, so this seems to be a build
>>> system bug.
>>>
>>> The last commit in GHC that I tried and succeeded to compile 2 weeks ago
>>> with a very similar setup as yours was this:
>>> 12332f1add3eb9615a62abb36898819b2e67e865
>>>
>>> Can you please try that so we can rule on whether there was a change
>>> very recently that broke this.
>>>
>>>> I am even running 'patchPhase && configurePhase && buildPhase' which
>>>> should technically be exactly what nix does with the package in nixpkgs.
>>>> By the way, the official nix package for HEAD isn't quite HEAD but
>>>> instead a snapshot of somewhere near HEAD and in fact I'm the person
>>>> that opened an issue and a PR to get that updated. The fact that it
>>>> builds that but doesn't build when I'm in the source tree makes me
>>>> wonder what's different.
>>>
>>> I see.  I'm flying out in 10 hours for vacation, so won't have time to
>>> reproduce your issue and look into this more deeply.  If you figure out
>>> what's happening, please send me a summary.
>>
>> Enjoy your vacation.
>>
>>> Maybe you should move this thread to the gmane.linux.distributions.nixos
>>> mailing list from here, because I guess Peter Simons and co can help you
>>> more with this, than GHC devs.
>>
>> Perhaps I should. I have tried with --with-intree-gmp and
>> DYNAMIC_BY_DEFAULT=OFF and they both fail at the same time. Next stop is
>> to try to build from some snapshots to see whether the  problem is recent.
>>
>>> If I find the bandwidth during travels, I will try to keep an eye on this.
>>>
>>> Gergely
>>>
>>
>>
> 
> Today I built the snapshots from 20140430[1] and 20140510[2] without a
> problem (just had to not build the postscript docs as those failed)
> which makes me think there's either something wrong with my tree or
> these snapshots do something that stops the problem from coming up.
> 
> [1]: http://deb.haskell.org/dailies/2014-04-30/ghc_7.9.20140430.orig.tar.bz2
> [2]: http://deb.haskell.org/dailies/2014-05-11/ghc_7.9.20140510.orig.tar.bz2
> 

After these attempts, I deleted my whole ghc tree and cloned it fresh.
It has built successfully. Clearly ‘make clean’ is not doing its job
properly somewhere but at this point I'm just happy I finally got it to
build.

-- 
Mateusz K.