Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 6352 - emerge ghc fails
Summary: emerge ghc fails
Status: RESOLVED DUPLICATE of bug 10155
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Development (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: George Shapovalov (RETIRED)
Depends on: 5318
Blocks: 12836
  Show dependency tree
Reported: 2002-08-12 04:43 UTC by Ole Tange
Modified: 2005-07-17 13:06 UTC (History)
3 users (show)

See Also:
Package list:
Runtime testing required: ---

output from emerge ghc (ghc,89.84 KB, text/plain)
2002-08-12 04:48 UTC, Ole Tange
output from emerge ghc (the fooX are mine) (ghc,89.98 KB, text/plain)
2002-08-20 17:20 UTC, Ole Tange
emerge of ghc 5.02.3 (ghc,23.49 KB, application/octet-stream)
2002-08-21 03:55 UTC, Ole Tange
strace of genprimopcode (strace,2.17 KB, text/plain)
2002-08-21 07:54 UTC, Ole Tange

Note You need to log in before you can comment on or make changes to this bug.
Description Ole Tange 2002-08-12 04:43:56 UTC
Comment 1 Ole Tange 2002-08-12 04:47:28 UTC
(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. 
Comment 2 Ole Tange 2002-08-12 04:48:13 UTC
Created attachment 3011 [details]
output from emerge ghc
Comment 3 Ole Tange 2002-08-14 10:00:24 UTC
I rsynced a new version. Same problem: 
/usr/sbin/ $: command not found 
/usr/sbin/ $: command not found 
/usr/sbin/ $: command not found 
/usr/sbin/ $: 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. warning: AC_TRY_RUN called without default to allow cross 
fptools configure script wizard sez: autoconf-2.50 or later should produce no 
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) 
Comment 4 George Shapovalov (RETIRED) gentoo-dev 2002-08-16 20:56:17 UTC
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.

Comment 5 Ole Tange 2002-08-20 17:00:40 UTC
rsynced to new version. Same problem. 
# gcc --version 
# 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 # 
Comment 6 Ole Tange 2002-08-20 17:09:38 UTC
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 
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: 
and it gets a lot further now. 
Comment 7 Ole Tange 2002-08-20 17:20:12 UTC
Created attachment 3244 [details]
output from emerge ghc (the fooX are mine)
Comment 8 George Shapovalov (RETIRED) gentoo-dev 2002-08-20 23:01:35 UTC
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).


Comment 9 Ole Tange 2002-08-21 02:26:24 UTC
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? 
Comment 10 George Shapovalov (RETIRED) gentoo-dev 2002-08-21 03:36:37 UTC
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.

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?

Comment 11 Ole Tange 2002-08-21 03:54:36 UTC
# epm -q ghc

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.
Comment 12 Ole Tange 2002-08-21 03:55:28 UTC
Created attachment 3251 [details]
emerge of ghc 5.02.3
Comment 13 Sven Moritz Hallberg 2002-08-21 07:00:22 UTC
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.
Comment 14 Ole Tange 2002-08-21 07:48:41 UTC
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 $? 
medi genprimopcode # 
Comment 15 Ole Tange 2002-08-21 07:54:07 UTC
I have found "something":  
medi compiler # pwd  
medi compiler # ../utils/genprimopcode/genprimopcode --data-decl          <  
prelude/primops.txt > primop-data-decl.hs-incl  
Segmentation fault  
# echo $?  
an strace of genprimopcode is attached.  
Comment 16 Ole Tange 2002-08-21 07:54:36 UTC
Created attachment 3253 [details]
strace of genprimopcode
Comment 17 Ole Tange 2002-08-21 08:05:21 UTC
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. 
Comment 18 Sven Moritz Hallberg 2002-08-21 08:59:26 UTC
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 asking for assistance
in this issue.
Comment 19 Sven Moritz Hallberg 2002-08-23 10:41:59 UTC
Quoting Simon Marlow <>'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/ for details).  Compile up something that
crashes, investigate with gdb, and we'll take it from there.


I hope this helps.
Comment 20 Ole Tange 2002-08-24 04:16:14 UTC
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. 
Comment 21 Andres Loeh (RETIRED) gentoo-dev 2002-12-06 06:52:02 UTC
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 ... 
Comment 22 Ole Tange 2002-12-06 06:59:41 UTC
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. 
Comment 23 George Shapovalov (RETIRED) gentoo-dev 2003-02-09 02:00:04 UTC

*** This bug has been marked as a duplicate of 10155 ***