Bugzilla Bug 6352

(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 an attachment (id=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 an attachment (id=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 an attachment (id=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 an attachment (id=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 ***