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)

Hi, Trying to compile GHC in the source tree on NixOS and meeting with failure with: "inplace/bin/ghc-stage2" -hisuf hi -osuf o -hcsuf hc -static -H32m -O -Werror -Wall -H64m -O0 -package-name vector-0.10.9.1 -hide-all-packages -i -ilibraries/vector/. -ilibraries/vector/dist-install/build -ilibraries/vector/dist-install/build/autogen -Ilibraries/vector/dist-install/build -Ilibraries/vector/dist-install/build/autogen -Ilibraries/vector/include -Ilibraries/vector/internal -optP-DVECTOR_BOUNDS_CHECKS -optP-include -optPlibraries/vector/dist-install/build/autogen/cabal_macros.h -package base-4.7.1.0 -package deepseq-1.3.0.2 -package ghc-prim-0.3.1.0 -package primitive-0.5.2.1 -O2 -XHaskell98 -XCPP -XDeriveDataTypeable -O2 -O -dcore-lint -fno-warn-deprecated-flags -no-user-package-db -rtsopts -Wwarn -odir libraries/vector/dist-install/build -hidir libraries/vector/dist-install/build -stubdir libraries/vector/dist-install/build -dynamic-too -c libraries/vector/./Data/Vector/Fusion/Stream/Monadic.hs -o libraries/vector/dist-install/build/Data/Vector/Fusion/Stream/Monadic.o -dyno libraries/vector/dist-install/build/Data/Vector/Fusion/Stream/Monadic.dyn_o Loading package ghc-prim ... linking ... done. 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) While libgmp isn't anywhere obvious, below is my build.mk and content of the pointed-to directories. Am I missing something here? Is something ignoring the configure option maybe? [shana@lenalee:~/programming/ghc/mk]$ cat build.mk libraries/integer-gmp_CONFIGURE_OPTS += --configure-option=--with-gmp-libraries=/nix/store/qnkyas42nf0knps3va30y29y3zvmgy2v-gmp-5.1.3/lib libraries/integer-gmp_CONFIGURE_OPTS += --configure-option=--with-gmp-includes=/nix/store/qnkyas42nf0knps3va30y29y3zvmgy2v-gmp-5.1.3/include DYNAMIC_BY_DEFAULT = NO [shana@lenalee:~/programming/ghc/mk]$ l /nix/store/qnkyas42nf0knps3va30y29y3zvmgy2v-gmp-5.1.3/lib total 604K dr-xr-xr-x 2 root nixbld 4.0K Jan 1 1970 . dr-xr-xr-x 5 root nixbld 4.0K Jan 1 1970 .. -r-xr-xr-x 1 root nixbld 949 Jan 1 1970 libgmp.la lrwxrwxrwx 1 root nixbld 16 Jan 1 1970 libgmp.so -> libgmp.so.10.1.3 lrwxrwxrwx 1 root nixbld 16 Jan 1 1970 libgmp.so.10 -> libgmp.so.10.1.3 -r-xr-xr-x 1 root nixbld 556K Jan 1 1970 libgmp.so.10.1.3 -r-xr-xr-x 1 root nixbld 1.1K Jan 1 1970 libgmpxx.la lrwxrwxrwx 1 root nixbld 17 Jan 1 1970 libgmpxx.so -> libgmpxx.so.4.3.3 lrwxrwxrwx 1 root nixbld 17 Jan 1 1970 libgmpxx.so.4 -> libgmpxx.so.4.3.3 -r-xr-xr-x 1 root nixbld 30K Jan 1 1970 libgmpxx.so.4.3.3 [shana@lenalee:~/programming/ghc/mk]$ l /nix/store/qnkyas42nf0knps3va30y29y3zvmgy2v-gmp-5.1.3/include total 204K dr-xr-xr-x 2 root nixbld 4.0K Jan 1 1970 . dr-xr-xr-x 5 root nixbld 4.0K Jan 1 1970 .. -r--r--r-- 1 root nixbld 78K Jan 1 1970 gmp.h -r--r--r-- 1 root nixbld 114K Jan 1 1970 gmpxx.h -- Mateusz K.

Hi,
Interesting. You're already using the libraries/integer-gmp_CONFIGURE_OPTS
magic that I wanted to advise.
I think you should record the configure and build output, so it's easy
to look around in it afterwards (and don't use -j for make, because then
the output is mixed). I would look for gmp relevant bits in that, to
see if it found it alright. You can also try --with-intree-gmp (or
something like that) to force a statically linked intree gmp, that will
just work.
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
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.
But I'd really like to understand what caused it, so if you have time,
please investigate!
Gergely
On Sun, 11 May 2014 16:27:01 +0200, Mateusz Kowalczyk
Hi,
Trying to compile GHC in the source tree on NixOS and meeting with failure with:
"inplace/bin/ghc-stage2" -hisuf hi -osuf o -hcsuf hc -static -H32m -O -Werror -Wall -H64m -O0 -package-name vector-0.10.9.1 -hide-all-packages -i -ilibraries/vector/. -ilibraries/vector/dist-install/build -ilibraries/vector/dist-install/build/autogen -Ilibraries/vector/dist-install/build -Ilibraries/vector/dist-install/build/autogen -Ilibraries/vector/include -Ilibraries/vector/internal -optP-DVECTOR_BOUNDS_CHECKS -optP-include -optPlibraries/vector/dist-install/build/autogen/cabal_macros.h -package base-4.7.1.0 -package deepseq-1.3.0.2 -package ghc-prim-0.3.1.0 -package primitive-0.5.2.1 -O2 -XHaskell98 -XCPP -XDeriveDataTypeable -O2 -O -dcore-lint -fno-warn-deprecated-flags -no-user-package-db -rtsopts -Wwarn -odir libraries/vector/dist-install/build -hidir libraries/vector/dist-install/build -stubdir libraries/vector/dist-install/build -dynamic-too -c libraries/vector/./Data/Vector/Fusion/Stream/Monadic.hs -o libraries/vector/dist-install/build/Data/Vector/Fusion/Stream/Monadic.o -dyno libraries/vector/dist-install/build/Data/Vector/Fusion/Stream/Monadic.dyn_o Loading package ghc-prim ... linking ... done. 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)
While libgmp isn't anywhere obvious, below is my build.mk and content of the pointed-to directories. Am I missing something here? Is something ignoring the configure option maybe?
[shana@lenalee:~/programming/ghc/mk]$ cat build.mk libraries/integer-gmp_CONFIGURE_OPTS += --configure-option=--with-gmp-libraries=/nix/store/qnkyas42nf0knps3va30y29y3zvmgy2v-gmp-5.1.3/lib libraries/integer-gmp_CONFIGURE_OPTS += --configure-option=--with-gmp-includes=/nix/store/qnkyas42nf0knps3va30y29y3zvmgy2v-gmp-5.1.3/include DYNAMIC_BY_DEFAULT = NO
[shana@lenalee:~/programming/ghc/mk]$ l /nix/store/qnkyas42nf0knps3va30y29y3zvmgy2v-gmp-5.1.3/lib total 604K dr-xr-xr-x 2 root nixbld 4.0K Jan 1 1970 . dr-xr-xr-x 5 root nixbld 4.0K Jan 1 1970 .. -r-xr-xr-x 1 root nixbld 949 Jan 1 1970 libgmp.la lrwxrwxrwx 1 root nixbld 16 Jan 1 1970 libgmp.so -> libgmp.so.10.1.3 lrwxrwxrwx 1 root nixbld 16 Jan 1 1970 libgmp.so.10 -> libgmp.so.10.1.3 -r-xr-xr-x 1 root nixbld 556K Jan 1 1970 libgmp.so.10.1.3 -r-xr-xr-x 1 root nixbld 1.1K Jan 1 1970 libgmpxx.la lrwxrwxrwx 1 root nixbld 17 Jan 1 1970 libgmpxx.so -> libgmpxx.so.4.3.3 lrwxrwxrwx 1 root nixbld 17 Jan 1 1970 libgmpxx.so.4 -> libgmpxx.so.4.3.3 -r-xr-xr-x 1 root nixbld 30K Jan 1 1970 libgmpxx.so.4.3.3
[shana@lenalee:~/programming/ghc/mk]$ l /nix/store/qnkyas42nf0knps3va30y29y3zvmgy2v-gmp-5.1.3/include total 204K dr-xr-xr-x 2 root nixbld 4.0K Jan 1 1970 . dr-xr-xr-x 5 root nixbld 4.0K Jan 1 1970 .. -r--r--r-- 1 root nixbld 78K Jan 1 1970 gmp.h -r--r--r-- 1 root nixbld 114K Jan 1 1970 gmpxx.h

On 05/11/2014 04:27 PM, Mateusz Kowalczyk wrote:
Hi,
Trying to compile GHC in the source tree on NixOS and meeting with failure with:
"inplace/bin/ghc-stage2" -hisuf hi -osuf o -hcsuf hc -static -H32m -O -Werror -Wall -H64m -O0 -package-name vector-0.10.9.1 -hide-all-packages -i -ilibraries/vector/. -ilibraries/vector/dist-install/build -ilibraries/vector/dist-install/build/autogen -Ilibraries/vector/dist-install/build -Ilibraries/vector/dist-install/build/autogen -Ilibraries/vector/include -Ilibraries/vector/internal -optP-DVECTOR_BOUNDS_CHECKS -optP-include -optPlibraries/vector/dist-install/build/autogen/cabal_macros.h -package base-4.7.1.0 -package deepseq-1.3.0.2 -package ghc-prim-0.3.1.0 -package primitive-0.5.2.1 -O2 -XHaskell98 -XCPP -XDeriveDataTypeable -O2 -O -dcore-lint -fno-warn-deprecated-flags -no-user-package-db -rtsopts -Wwarn -odir libraries/vector/dist-install/build -hidir libraries/vector/dist-install/build -stubdir libraries/vector/dist-install/build -dynamic-too -c libraries/vector/./Data/Vector/Fusion/Stream/Monadic.hs -o libraries/vector/dist-install/build/Data/Vector/Fusion/Stream/Monadic.o -dyno libraries/vector/dist-install/build/Data/Vector/Fusion/Stream/Monadic.dyn_o Loading package ghc-prim ... linking ... done. 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)
While libgmp isn't anywhere obvious, below is my build.mk and content of the pointed-to directories. Am I missing something here? Is something ignoring the configure option maybe?
[shana@lenalee:~/programming/ghc/mk]$ cat build.mk libraries/integer-gmp_CONFIGURE_OPTS += --configure-option=--with-gmp-libraries=/nix/store/qnkyas42nf0knps3va30y29y3zvmgy2v-gmp-5.1.3/lib libraries/integer-gmp_CONFIGURE_OPTS += --configure-option=--with-gmp-includes=/nix/store/qnkyas42nf0knps3va30y29y3zvmgy2v-gmp-5.1.3/include DYNAMIC_BY_DEFAULT = NO
[shana@lenalee:~/programming/ghc/mk]$ l /nix/store/qnkyas42nf0knps3va30y29y3zvmgy2v-gmp-5.1.3/lib total 604K dr-xr-xr-x 2 root nixbld 4.0K Jan 1 1970 . dr-xr-xr-x 5 root nixbld 4.0K Jan 1 1970 .. -r-xr-xr-x 1 root nixbld 949 Jan 1 1970 libgmp.la lrwxrwxrwx 1 root nixbld 16 Jan 1 1970 libgmp.so -> libgmp.so.10.1.3 lrwxrwxrwx 1 root nixbld 16 Jan 1 1970 libgmp.so.10 -> libgmp.so.10.1.3 -r-xr-xr-x 1 root nixbld 556K Jan 1 1970 libgmp.so.10.1.3 -r-xr-xr-x 1 root nixbld 1.1K Jan 1 1970 libgmpxx.la lrwxrwxrwx 1 root nixbld 17 Jan 1 1970 libgmpxx.so -> libgmpxx.so.4.3.3 lrwxrwxrwx 1 root nixbld 17 Jan 1 1970 libgmpxx.so.4 -> libgmpxx.so.4.3.3 -r-xr-xr-x 1 root nixbld 30K Jan 1 1970 libgmpxx.so.4.3.3
[shana@lenalee:~/programming/ghc/mk]$ l /nix/store/qnkyas42nf0knps3va30y29y3zvmgy2v-gmp-5.1.3/include total 204K dr-xr-xr-x 2 root nixbld 4.0K Jan 1 1970 . dr-xr-xr-x 5 root nixbld 4.0K Jan 1 1970 .. -r--r--r-- 1 root nixbld 78K Jan 1 1970 gmp.h -r--r--r-- 1 root nixbld 114K Jan 1 1970 gmpxx.h
You can find the full build log (including make clean) at [1] as it was requested in private. [1]: http://fuuzetsu.co.uk/misc/ghclog-20140510 -- Mateusz K.

From your build log: checking for __gmpz_powm in -lgmp... yes checking for __gmpz_powm_sec in -lgmp... yes ... checking gmp.h usability... yes checking gmp.h presence... yes checking for gmp.h... yes
Searching for qnkyas42nf0knps3va30y29y3zvmgy2v in your build log, it's also seems so that the build.mk lines have effect and both the lib and the include line is correctly passed in. Can it be, that the "DYNAMIC_BY_DEFAULT = NO" is causing the issue? May I ask you to try without that? Not as a final solution, just as a try? Maybe you will have to add "GhcLibWays = v dyn" too, I usually not remove the whole build.mk, just use the build.mk.sample with quick and then add my additional stuff, like the gmp lines that are needed for NixOS. And again, an strace on "ghc-stage2 --interactive" with "-ff -e file" and grepping for libgmp would be very useful. Gergely

The following message is a courtesy copy of an article that has been posted to gmane.comp.lang.haskell.ghc.devel as well.
Hi,
Interesting. You're already using the
On 05/11/2014 05:19 PM, Gergely Risko wrote: libraries/integer-gmp_CONFIGURE_OPTS
magic that I wanted to advise.
I think you should record the configure and build output, so it's easy to look around in it afterwards (and don't use -j for make, because then the output is mixed). I would look for gmp relevant bits in that, to see if it found it alright. You can also try --with-intree-gmp (or something like that) to force a statically linked intree gmp, that will just work.
I have posted the log in my previous reply to the thread. I'm unsure what -j option was used, I forgot to switch it off. Let me know if you want it re-ran without -j. Do you know what exact setup I need for --with-intree-gmp?
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.
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.
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.
Gergely
On Sun, 11 May 2014 16:27:01 +0200, Mateusz Kowalczyk
writes: Hi,
Trying to compile GHC in the source tree on NixOS and meeting with failure with:
"inplace/bin/ghc-stage2" -hisuf hi -osuf o -hcsuf hc -static -H32m -O -Werror -Wall -H64m -O0 -package-name vector-0.10.9.1 -hide-all-packages -i -ilibraries/vector/. -ilibraries/vector/dist-install/build -ilibraries/vector/dist-install/build/autogen -Ilibraries/vector/dist-install/build -Ilibraries/vector/dist-install/build/autogen -Ilibraries/vector/include -Ilibraries/vector/internal -optP-DVECTOR_BOUNDS_CHECKS -optP-include -optPlibraries/vector/dist-install/build/autogen/cabal_macros.h -package base-4.7.1.0 -package deepseq-1.3.0.2 -package ghc-prim-0.3.1.0 -package primitive-0.5.2.1 -O2 -XHaskell98 -XCPP -XDeriveDataTypeable -O2 -O -dcore-lint -fno-warn-deprecated-flags -no-user-package-db -rtsopts -Wwarn -odir libraries/vector/dist-install/build -hidir libraries/vector/dist-install/build -stubdir libraries/vector/dist-install/build -dynamic-too -c libraries/vector/./Data/Vector/Fusion/Stream/Monadic.hs -o libraries/vector/dist-install/build/Data/Vector/Fusion/Stream/Monadic.o -dyno
Loading package ghc-prim ... linking ... done. 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)
While libgmp isn't anywhere obvious, below is my build.mk and content of the pointed-to directories. Am I missing something here? Is something ignoring the configure option maybe?
[shana@lenalee:~/programming/ghc/mk]$ cat build.mk libraries/integer-gmp_CONFIGURE_OPTS +=
--configure-option=--with-gmp-libraries=/nix/store/qnkyas42nf0knps3va30y29y3zvmgy2v-gmp-5.1.3/lib
libraries/integer-gmp_CONFIGURE_OPTS +=
--configure-option=--with-gmp-includes=/nix/store/qnkyas42nf0knps3va30y29y3zvmgy2v-gmp-5.1.3/include
DYNAMIC_BY_DEFAULT = NO
[shana@lenalee:~/programming/ghc/mk]$ l /nix/store/qnkyas42nf0knps3va30y29y3zvmgy2v-gmp-5.1.3/lib total 604K dr-xr-xr-x 2 root nixbld 4.0K Jan 1 1970 . dr-xr-xr-x 5 root nixbld 4.0K Jan 1 1970 .. -r-xr-xr-x 1 root nixbld 949 Jan 1 1970 libgmp.la lrwxrwxrwx 1 root nixbld 16 Jan 1 1970 libgmp.so -> libgmp.so.10.1.3 lrwxrwxrwx 1 root nixbld 16 Jan 1 1970 libgmp.so.10 ->
-r-xr-xr-x 1 root nixbld 556K Jan 1 1970 libgmp.so.10.1.3 -r-xr-xr-x 1 root nixbld 1.1K Jan 1 1970 libgmpxx.la lrwxrwxrwx 1 root nixbld 17 Jan 1 1970 libgmpxx.so ->
Apologies for those using threaded conversations, I have no idea how to reply to something that shows up as a newsgroup posting from my e-mail client, it seems Reply-To doesn't get set. libraries/vector/dist-install/build/Data/Vector/Fusion/Stream/Monadic.dyn_o libgmp.so.10.1.3 libgmpxx.so.4.3.3
lrwxrwxrwx 1 root nixbld 17 Jan 1 1970 libgmpxx.so.4 -> libgmpxx.so.4.3.3 -r-xr-xr-x 1 root nixbld 30K Jan 1 1970 libgmpxx.so.4.3.3
[shana@lenalee:~/programming/ghc/mk]$ l /nix/store/qnkyas42nf0knps3va30y29y3zvmgy2v-gmp-5.1.3/include total 204K dr-xr-xr-x 2 root nixbld 4.0K Jan 1 1970 . dr-xr-xr-x 5 root nixbld 4.0K Jan 1 1970 .. -r--r--r-- 1 root nixbld 78K Jan 1 1970 gmp.h -r--r--r-- 1 root nixbld 114K Jan 1 1970 gmpxx.h
-- Mateusz K.

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

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.

On Sun, 11 May 2014 21:42:45 +0200, Mateusz Kowalczyk
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] open("/home/shana/programming/ghc/libraries/haskeline/dist-install/build/libgmp.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) [pid 10676] open("/home/shana/programming/ghc/libraries/terminfo/dist-install/build/libgmp.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) [pid 10676] open("/home/shana/programming/ghc/compiler/stage2/build/libgmp.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) [pid 10676] open("/home/shana/programming/ghc/libraries/transformers/dist-install/build/libgmp.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) [pid 10676] open("/home/shana/programming/ghc/libraries/template-haskell/dist-install/build/libgmp.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) [pid 10676] open("/home/shana/programming/ghc/libraries/hpc/dist-install/build/libgmp.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) [pid 10676] open("/home/shana/programming/ghc/libraries/hoopl/dist-install/build/libgmp.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) [pid 10676] open("/home/shana/programming/ghc/libraries/bin-package-db/dist-install/build/libgmp.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) [pid 10676] open("/home/shana/programming/ghc/libraries/binary/dist-install/build/libgmp.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) [pid 10676] open("/home/shana/programming/ghc/libraries/Cabal/Cabal/dist-install/build/libgmp.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) [pid 10676] open("/home/shana/programming/ghc/libraries/process/dist-install/build/libgmp.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) [pid 10676] open("/home/shana/programming/ghc/libraries/pretty/dist-install/build/libgmp.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) [pid 10676] open("/home/shana/programming/ghc/libraries/directory/dist-install/build/libgmp.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) [pid 10676] open("/home/shana/programming/ghc/libraries/unix/dist-install/build/libgmp.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) [pid 10676] open("/home/shana/programming/ghc/libraries/time/dist-install/build/libgmp.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) [pid 10676] open("/home/shana/programming/ghc/libraries/old-locale/dist-install/build/libgmp.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) [pid 10676] open("/home/shana/programming/ghc/libraries/filepath/dist-install/build/libgmp.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) [pid 10676] open("/home/shana/programming/ghc/libraries/containers/dist-install/build/libgmp.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) [pid 10676] open("/home/shana/programming/ghc/libraries/bytestring/dist-install/build/libgmp.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) [pid 10676] open("/home/shana/programming/ghc/libraries/deepseq/dist-install/build/libgmp.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) [pid 10676] open("/home/shana/programming/ghc/libraries/array/dist-install/build/libgmp.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) [pid 10676] open("/home/shana/programming/ghc/libraries/base/dist-install/build/libgmp.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) [pid 10676] open("/home/shana/programming/ghc/libraries/integer-gmp/dist-install/build/libgmp.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) [pid 10676] open("/home/shana/programming/ghc/libraries/ghc-prim/dist-install/build/libgmp.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) [pid 10676] open("/home/shana/programming/ghc/rts/dist/build/libgmp.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) [pid 10676] open("/run/opengl-driver/lib/tls/libgmp.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) [pid 10676] open("/run/opengl-driver/lib/libgmp.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) [pid 10676] open("/run/opengl-driver-32/lib/tls/libgmp.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) [pid 10676] open("/run/opengl-driver-32/lib/libgmp.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) [pid 10676] open("/home/shana/programming/ghc/rts/dist/build/libgmp.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) [pid 10676] open("/nix/store/4v0a2fncxsk2f57jixq7i59k6hdl34fx-glibc-2.19/lib/libgmp.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) [pid 10676] open("/nix/store/n5hl6lpm87mxf4qd8f2zq423al1gwdj9-gcc-4.8.2/lib/libgmp.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) [pid 10676] open("/nix/store/4v0a2fncxsk2f57jixq7i59k6hdl34fx-glibc-2.19/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) [pid 10676] open("/nix/store/4v0a2fncxsk2f57jixq7i59k6hdl34fx-glibc-2.19/lib/libgmp.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) <command line>: can't load .so/.DLL for: libgmp.so (libgmp.so: cannot open shared object file: No such file or directory) 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. 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. If I find the bandwidth during travels, I will try to keep an eye on this. Gergely

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
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] open("/home/shana/programming/ghc/libraries/haskeline/dist-install/build/libgmp.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) [pid 10676] open("/home/shana/programming/ghc/libraries/terminfo/dist-install/build/libgmp.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) [pid 10676] open("/home/shana/programming/ghc/compiler/stage2/build/libgmp.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) [pid 10676] open("/home/shana/programming/ghc/libraries/transformers/dist-install/build/libgmp.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) [pid 10676] open("/home/shana/programming/ghc/libraries/template-haskell/dist-install/build/libgmp.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) [pid 10676] open("/home/shana/programming/ghc/libraries/hpc/dist-install/build/libgmp.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) [pid 10676] open("/home/shana/programming/ghc/libraries/hoopl/dist-install/build/libgmp.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) [pid 10676] open("/home/shana/programming/ghc/libraries/bin-package-db/dist-install/build/libgmp.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) [pid 10676] open("/home/shana/programming/ghc/libraries/binary/dist-install/build/libgmp.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) [pid 10676] open("/home/shana/programming/ghc/libraries/Cabal/Cabal/dist-install/build/libgmp.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) [pid 10676] open("/home/shana/programming/ghc/libraries/process/dist-install/build/libgmp.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) [pid 10676] open("/home/shana/programming/ghc/libraries/pretty/dist-install/build/libgmp.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) [pid 10676] open("/home/shana/programming/ghc/libraries/directory/dist-install/build/libgmp.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) [pid 10676] open("/home/shana/programming/ghc/libraries/unix/dist-install/build/libgmp.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) [pid 10676] open("/home/shana/programming/ghc/libraries/time/dist-install/build/libgmp.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) [pid 10676] open("/home/shana/programming/ghc/libraries/old-locale/dist-install/build/libgmp.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) [pid 10676] open("/home/shana/programming/ghc/libraries/filepath/dist-install/build/libgmp.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) [pid 10676] open("/home/shana/programming/ghc/libraries/containers/dist-install/build/libgmp.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) [pid 10676] open("/home/shana/programming/ghc/libraries/bytestring/dist-install/build/libgmp.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) [pid 10676] open("/home/shana/programming/ghc/libraries/deepseq/dist-install/build/libgmp.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) [pid 10676] open("/home/shana/programming/ghc/libraries/array/dist-install/build/libgmp.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) [pid 10676] open("/home/shana/programming/ghc/libraries/base/dist-install/build/libgmp.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) [pid 10676] open("/home/shana/programming/ghc/libraries/integer-gmp/dist-install/build/libgmp.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) [pid 10676] open("/home/shana/programming/ghc/libraries/ghc-prim/dist-install/build/libgmp.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) [pid 10676] open("/home/shana/programming/ghc/rts/dist/build/libgmp.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) [pid 10676] open("/run/opengl-driver/lib/tls/libgmp.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) [pid 10676] open("/run/opengl-driver/lib/libgmp.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) [pid 10676] open("/run/opengl-driver-32/lib/tls/libgmp.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) [pid 10676] open("/run/opengl-driver-32/lib/libgmp.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) [pid 10676] open("/home/shana/programming/ghc/rts/dist/build/libgmp.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) [pid 10676] open("/nix/store/4v0a2fncxsk2f57jixq7i59k6hdl34fx-glibc-2.19/lib/libgmp.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) [pid 10676] open("/nix/store/n5hl6lpm87mxf4qd8f2zq423al1gwdj9-gcc-4.8.2/lib/libgmp.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) [pid 10676] open("/nix/store/4v0a2fncxsk2f57jixq7i59k6hdl34fx-glibc-2.19/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) [pid 10676] open("/nix/store/4v0a2fncxsk2f57jixq7i59k6hdl34fx-glibc-2.19/lib/libgmp.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) <command line>: can't load .so/.DLL for: libgmp.so (libgmp.so: cannot open shared object file: No such file or directory)
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
-- Mateusz K.

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
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 -- Mateusz K.

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
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.
participants (2)
-
Gergely Risko
-
Mateusz Kowalczyk