Re: 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)

On 05/11/2014 09:19 PM, Gergely Risko wrote:

On Sun, 11 May 2014 21:00:16 +0200, Mateusz Kowalczyk 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.

Are there any downsides to doing this except slightly bigger binary size?

...

...

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.

Sorry, you're correct, I did not pass interactive. Find attached the strace with --interactive.

...

...

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.

Actually, I'm doing this already: https://github.com/Fuuzetsu/nix-project-defaults/blob/master/ghc/default.nix 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.

Gergely

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs

-- Mateusz K.