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)

Gergely Risko gergely at risko.hu
Sun May 11 19:19:32 UTC 2014


On Sun, 11 May 2014 21:00:16 +0200, Mateusz Kowalczyk <fuuzetsu at fuuzetsu.co.uk> writes:

> Do you know what exact setup I need for --with-intree-gmp?

Nothing special is needed, actually it's autoselected if no gmp is found
during build.  (So e.g. on NixOS, where libraries are not just randomly
around everywhere in /usr/lib and /usr/include.)

So either get rid of your options and make GHC unable to find a gmp or
pass --with-intree-gmp to configure.

It's intree, because there is a gmp tar.gz intree inside the GHC source
tree, and with this option it just gets unpacked, compiled and used
statically for the build.  Furthermore, the resulting GHC will build
binaries that statically contain the biginteger GMP code, so it's a
useful hack to know about.

>> Also, I think "inplace/bin/ghc-stage2 --interactive" will fail with the
>> same error message, and you can "strace -f -e file" that command to see
>> where the libgmp.so is searched for. It should definitely be searched
>> for in your /nix/store/qnky...  directory with your build.mk.  I use the
>> same strategy here:
>> https://github.com/nilcons/ceh/blob/master/README.compile-ghc-with-ceh
>
> You're right that stage2 --interactive fails with the error. I attach
> the result of strace. It seems like a whole lot of stuff is missing.

>From your strace log:
-=-
[pid  8458] --- SIGVTALRM {si_signo=SIGVTALRM, si_code=SI_TIMER, si_pid=0, si_uid=0, si_value=0} ---
ghc-stage2: no input files
Usage: For basic information, try the `--help' option.
-=-

This is not an strace of a failing "ghc-stage2 --interactive".  That
wouldn't say "no input files".  Please first reproduce your error then
once you have the error, run the same command line with strace.  Thanks.

>> If you just want to quickly try something and not really interested in
>> figuring out what's wrong, then a quick and dirty fix is to
>> "export
> LD_LIBRARY_PATH=/nix/store/qnkyas42nf0knps3va30y29y3zvmgy2v-gmp-5.1.3/lib"
>> before the whole build or anytime afterwards when you want to use the
>> compiled GHC.
>
> That's not an option considering that particular store might be garbage
> collected if it's not registered as being used. I'm unsure of the
> details but simply said that's a very bad workaround on my distro.

It was suggested as a "quick and dirty fix".  If you need this GHC build
to fix a GHC bug and test it for five minutes, then this is an option.
If you need it for days, than it's maybe not.

NixOS gc is not ran randomly (like Git's GC, e.g. for git push or pull),
only when you do nix-garbage-collect.  And actually building your GHC
correctly will not fix your garbage collection issue, because gmp is
searched for dynamically by TH and GHCi.  So if the store goes garbage
collected, you will be screwed anyways.

If you want to have a GHC bundle that can find the same GMP days or
months later, then you should look at the strace, grep for the locations
where libgmp is searched for and put your current GMP unto one of the
locations that you most like.  And then you can run nix garbage collect
without issues.  Of course, your libc for example can still go away and
then you'll be screwed all the same.

Just having a binary somewhere on the system built outside of Nix will
not guarantee the dependent libraries to be kept.  If you want that,
you'll have to register your build properly with nix.

>> But I'd really like to understand what caused it, so if you have time,
>> please investigate!
>
> I definitely need to solve this properly as I need GHC HEAD for
> development and I need to change the build system of it a bit for
> accommodate for some Haddock changes.

Then I would look into how GHC is currently build with NixOS (they
support building GHC HEAD) and build on top of that.  Write your own
derivation with the necessary Haddock changes and call nix-build on it.
Then you would get a /nix/store path with your freshly built GHC head
and that would actually guarantee the underlying libc and gmp to not go
away at garbage collection time.

Gergely



More information about the ghc-devs mailing list