(OK, I probably never get used to Konquerors default of submitting a form when pressing enter in a textfield). emerge \=dev-lang/ghc-5.04 fails. The output is attached.
Created attachment 3011 [details] output from emerge ghc
I rsynced a new version. Same problem: /usr/sbin/ebuild.sh: $: command not found /usr/sbin/ebuild.sh: $: command not found /usr/sbin/ebuild.sh: $: command not found /usr/sbin/ebuild.sh: $: command not found configure: WARNING: If you wanted to set the --build type, don't use --host. If a cross compiler is detected then cross compile mode will be used. configure: WARNING: If you wanted to set the --build type, don't use --host. If a cross compiler is detected then cross compile mode will be used. configure.in:1088: warning: AC_TRY_RUN called without default to allow cross compiling fptools configure script wizard sez: autoconf-2.50 or later should produce no warnings if you are using 2.13 or earlier you may get a (harmless) warning message. configure: warning: CFLAGS=-mcpu=i686 -O2 -pipe: invalid host type configure: warning: host_alias=i686-pc-linux-gnu: invalid host type configure: error: can only configure for one host and one target at a time make[1]: *** [configure] Error 1 make: *** [configure] Error 2 !!! ERROR: The ebuild did not complete successfully. !!! Function build_stage2, Line 11, Exitcode 2 !!! (no error message)
Hi Ole Thanks for the bug report. Could you please provide some more information: your gcc version C[XX]FLAGS you are using your CHOST setting (as specified in make.conf or command line) are you building for the same architecture? Anything else that might seem relevant. George
rsynced to new version. Same problem. # gcc --version 2.95.3 # grep FLAGS /etc/make.conf CFLAGS="-mcpu=i686 -O2 -pipe" CXXFLAGS="-mcpu=i686 -O2 -pipe" I have found 1 bug: in the ebuild you have a comment starting with $ not #
wow! fixing the $ made thing get a lot better. Now I get: /usr/bin/ghc -o ghc-pkg.bin -ldl -cpp -DPKG_TOOL -DWANT_PRETTY -package lang -package util -package text -O Main.o Package.o ParsePkgConfLite.o /usr/i686-pc-linux-gnu/bin/ld: cannot find -lgmp collect2: ld returned 1 exit status make[4]: *** [ghc-pkg.bin] Error 1 make[3]: *** [boot] Error 2 make[2]: *** [boot] Error 1 make[1]: *** [boot] Error 1 make[1]: Leaving directory `/hda6/var/tmp/portage/ghc-5.04/work/stage2-build/ghc' make: *** [all] Error 1 !!! ERROR: The ebuild did not complete successfully. !!! Function build_stage2, Line 11, Exitcode 2 !!! (no error message) !!! emerge aborting on /usr/portage/dev-lang/ghc/ghc-5.04.ebuild . If GHC depends on GMP it should say so. I added: >=dev-libs/gmp-1.0.0 and it gets a lot further now.
Created attachment 3244 [details] output from emerge ghc (the fooX are mine)
Hi Ole. Thanks for more testing and reports! I think gmp dependency was indeed overlooked. As for the $ instead of # I am quite lost - the ebuild was tested more than once (by me and its author) and built just fine. Admittedly this is not a crytical bug and may have been just lost in the output. I did both these corrections to the ebuild. As for the problem you experience while building the package: do you have some version of ghc already installed? Or do you by chance define or have GHC variable defined? Looks like your build does not start at stage1 but rather tries to go to stage2 immediately. If you have ghc installed than it probably does not behave the way new source expects it. If you do not have ghc installed such behavior is most likely caused by GHC variable defined somewhere in your login scripts (in this case you may force the correct build by unexporting the GHC var). Please let me know which of these situations do you have (and if you do have ghc installed, what is the active version and how it was built). Thanks! George
I have ghc installed. The version is app. 1 month older than this bugreport. I do not remember how it was compiled. Chances are though that is was compiled with the same settings. Do you want me to de-install ghc to see if it helps?
Hi Ole. >I have ghc installed. The version is app. 1 month older than this bugreport. Does this mean that you have ghc-5.02.3 installed via "emerge ghc" when previous version was the latest one? Or did you install ghc yourself prior to trying it through gentoo? Related to this: did you try to use previous ebuild (5.02.3) and if yes, did you have any problems with it? Also do you have GHC variable defined anywhere (as misset GHC var can cause some problems with the ebuild)? >Do you want me to de-install ghc to see if it helps? Sorry, I forgot to mention this. Yes, you can deinstall your present version and then emerge ghc from scratch. This should build and give you working ghc thus relieving your problem (but if it doesn't please let me know). However this does not resolve the issue with ebuild, as apparently it fails under certain conditions :( (namely preinstalled ghc of some older version). I think I will have to ask ebuild author to help me here, as I am just overlooking various dev categories and not really a ghc guru :/. Temporary solution may be to force full build (all three stages) independently of existing ghc on the system. Though it would be nice to make ebuild use preinstalled ghc as it can save quite some time during the build. Sven: Sorry for bothering you again. It seems that the ebuild of ghc-5.04 that you submitted and I processed (bug #5318) has some problems if ghc is already installed on the system. Could you please take a look at this bug? George
# epm -q ghc ghc-5.02.3 I have never tried installing it manually (without emerge). I had no problems with previous versions. I have not manually set GHC-variable and it seems not to be set. I have tried re-installing ghc-5.02.3. It did not work. See attached.
Created attachment 3251 [details] emerge of ghc 5.02.3
George, you have overlooked to change the patch files' extensions to .bz2 after changing to bzcat in ghc-5.02.3.ebuild. Please fix. That must be the cause of your last build failure (the patch adds support for the --without-happy configure option). As for the failure of the GHC 5.04 build before, I'm not yet quite sure what's causing it. The error message says that the genprimopcode program (it's written in Haskell and built along with the compiler) returned error code 139. This is strange, because the program code doesn't say anything about exit codes at all. Also the output doesn't contain any textual error indication from genprimopcode. So it looks to me as if the program actually ran successfully but the compiler which was used to build it did something wrong that makes genprimopcode return this strange exit code. My GHC 5.02.3, however, compiles main=return() to a program which indeed returns ExitSuccess. Ole, can you please try to run the genprimopcode command manually and check its exit status? The genprimopcode program should be in /var/tmp/portage/ghc-5.04/work/stage2-build/ghc/utils/genprimopcode. From there try $ ./genprimopcode --data-decl < ../../compiler/prelude/primops.txt > /dev/null $ echo $? If the last command prints 139, we've isolated the source of the bug. (It should be in /var/tmp/portage/ghc-5.04/work/ghc-5.
Hmm... sorry: # cd /var/tmp/portage/ghc-5.04/work/stage2-build/ghc/utils/genprimopcodemedi genprimopcode # medi genprimopcode # ./genprimopcode --data-decl < ../../compiler/prelude/primops.txt > /dev/null medi genprimopcode # echo $? 0 medi genprimopcode #
I have found "something": medi compiler # pwd /hda6/var/tmp/portage/ghc-5.04/work/stage3-build/ghc/compiler medi compiler # ../utils/genprimopcode/genprimopcode --data-decl < prelude/primops.txt > primop-data-decl.hs-incl Segmentation fault # echo $? 139 an strace of genprimopcode is attached.
Created attachment 3253 [details] strace of genprimopcode
hmmm.... it seems stage2 is OK. But stage3 is bad. Right now I am thinking: Is sandbox the problem? I don't remember how to disable sandbox, and 'man emerge' is not helpful on that either.
Oh, sorry I overlooked your build was already at stage 3. I have no idea now what's causing the strange segfault. I still have the complete build dirs of my last build of GHC 5.04 around in /var/tmp/portage, and genprimopcode works in all of them. I've sent a message to glasgow-haskell-users@haskell.org asking for assistance in this issue.
Quoting Simon Marlow <simonmar@microsoft.com>'s reply to my message: --- I'm afraid nothing springs to mind - but I do recall that genprimopcode is perhaps the first Haskell binary to be executed in a bootstrapped tree, so it could be just that the stage 2 compiler is building consistently broken binaries. That should be easy to verify. The next stage is to try to debug it. Compile up the runtime system (in the compiler tree that is generating broken code) with the debugging options (see mk/config.mk for details). Compile up something that crashes, investigate with gdb, and we'll take it from there. Cheers, Simon --- I hope this helps.
If I am not to waste an enormous lot of time doing the wrong things I will need a more explicit guide on what to do. A couple of shell commands would be nice.
I have a general (maybe stupid) question about the GHC ebuild: Wouldn't it be better to take a binary version of GHC (AFAIK available for both Intel and SPARC) to rebuild the source distribution once with personal settings? No building from HC-files would be necessary, and it might be less sensitive to differences in gcc-versions ...
I would very much like to see Gentoo work on all possible platforms with as small changes as possible. The only way I can see this done is by compiling as much as possible from source. By using the .hc-files I am sure it will be much easier to port GHC to, say, ARM.
*** This bug has been marked as a duplicate of 10155 ***
