Opened 6 years ago

Closed 5 years ago

Last modified 11 months ago

#8374 closed bug (fixed)

`tcIfaceGlobal (local): not found` while compiling

Reported by: bgamari Owned by: thoughtpolice
Priority: high Milestone: 7.10.1
Component: Build System (make) Version: 7.7
Keywords: Cc:
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: Building GHC failed Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:

Description (last modified by simonpj)

On commit fa3ffb43144eadc406031110b01ba3dc4f9bd94e on compiling on ARM,

"rm" -f libraries/integer-gmp/dist-install/build/libHSinteger-gmp-0.5.1.0.a.contents  
"/usr/bin/ld"  -r -o libraries/integer-gmp/dist-install/build/HSinteger-gmp-0.5.1.0.o  libraries/integer-gmp/dist-install/build/GHC/Integer.o libraries/integer-gmp/dist-install/build/GHC/Integer/GMP/Internals.o libraries/integer-gmp/dist-install/build/GHC/Integer/GMP/Prim.o libraries/integer-gmp/dist-install/build/GHC/Integer/Logarithms.o libraries/integer-gmp/dist-install/build/GHC/Integer/Logarithms/Internals.o libraries/integer-gmp/dist-install/build/GHC/Integer/Type.o libraries/integer-gmp/dist-install/build/cbits/gmp-wrappers.o  libraries/integer-gmp/dist-install/build/cbits/cbits.o   
ghc-stage1: panic! (the 'impossible' happened)
  (GHC version 7.7.20130924 for arm-unknown-linux):
        tcIfaceGlobal (local): not found:
    base:GHC.Base.$fMonadIO{v r1}
    [(02K, Identifier ‛base:GHC.Base.fail{v 02K}’),
     (02L, Identifier ‛base:GHC.Base.>>={v 02L}’),
     (02M, Identifier ‛base:GHC.Base.>>{v 02M}’),
     (02N, Identifier ‛base:GHC.Base.fmap{v 02N}’),
     (02O, Identifier ‛base:GHC.Base.return{v 02O}’),
     (28, Class ‛base:GHC.Base.Monad{tc 28}’),
     (2a, Class ‛base:GHC.Base.Functor{tc 2a}’),
     (36r, Type constructor ‛base:GHC.Base.Opaque{tc 36r}’),
     (36u, Type constructor ‛base:GHC.Base.String{tc 36u}’),
     (rB, Data constructor ‛base:GHC.Base.O{d rB}’),
     (rD, Identifier ‛base:GHC.Base.<${v rD}’),
     (rhP, Identifier ‛base:GHC.Base.O{v rhP}’),
     (ri5, Data constructor ‛base:GHC.Base.D:Functor{d ri5}’),
     (rit, Identifier ‛base:GHC.Base.$dm<${v rit}’),
     (riv, Identifier ‛base:GHC.Base.D:Functor{v riv}’),
     (riX, Data constructor ‛base:GHC.Base.D:Monad{d riX}’),
     (rjw, Identifier ‛base:GHC.Base.$dm>>{v rjw}’),
     (rjx, Identifier ‛base:GHC.Base.$dmfail{v rjx}’),
     (rjz, Identifier ‛base:GHC.Base.D:Monad{v rjz}’)]

Change History (35)

comment:1 Changed 6 years ago by bgamari

Hmm, apparently Github flavored Markdown doesn't work here. Let's try that again,

"inplace/bin/ghc-stage1" -hisuf hi -osuf  o -hcsuf hc -static  -H64m -O0 -fasm    -package-name base-4.7.0.0 -hide-all-packages -i -ilibraries/base/. -ilibraries/base/dist-install/build -ilibraries/base/dist-install/build/autogen -Ilibraries/base/dist-install/build -Ilibraries/base/dist-install/build/autogen -Ilibraries/base/include   -optP-DOPTIMISE_INTEGER_GCD_LCM -optP-include -optPlibraries/base/dist-install/build/autogen/cabal_macros.h -package ghc-prim-0.3.1.0 -package integer-gmp-0.5.1.0 -package rts-1.0 -package-name base -XHaskell98 -XCPP -O -fasm  -no-user-package-db -rtsopts      -odir libraries/base/dist-install/build -hidir libraries/base/dist-install/build -stubdir libraries/base/dist-install/build   -c libraries/base/./GHC/Base.lhs -o libraries/base/dist-install/build/GHC/Base.o 

when making flags consistent: Warning:
    No native code generator, so using LLVM
ghc-stage1: panic! (the 'impossible' happened)
  (GHC version 7.7.20130924 for arm-unknown-linux):
        tcIfaceGlobal (local): not found:
    base:GHC.Base.$fMonadIO{v r1}
    [(02K, Identifier ‛base:GHC.Base.fail{v 02K}’),
     (02L, Identifier ‛base:GHC.Base.>>={v 02L}’),
     (02M, Identifier ‛base:GHC.Base.>>{v 02M}’),
     (02N, Identifier ‛base:GHC.Base.fmap{v 02N}’),
     (02O, Identifier ‛base:GHC.Base.return{v 02O}’),
     (28, Class ‛base:GHC.Base.Monad{tc 28}’),
     (2a, Class ‛base:GHC.Base.Functor{tc 2a}’),
     (36r, Type constructor ‛base:GHC.Base.Opaque{tc 36r}’),
     (36u, Type constructor ‛base:GHC.Base.String{tc 36u}’),
     (rB, Data constructor ‛base:GHC.Base.O{d rB}’),
     (rD, Identifier ‛base:GHC.Base.<${v rD}’),
     (rhP, Identifier ‛base:GHC.Base.O{v rhP}’),
     (ri5, Data constructor ‛base:GHC.Base.D:Functor{d ri5}’),
     (rit, Identifier ‛base:GHC.Base.$dm<${v rit}’),
     (riv, Identifier ‛base:GHC.Base.D:Functor{v riv}’),
     (riX, Data constructor ‛base:GHC.Base.D:Monad{d riX}’),
     (rjw, Identifier ‛base:GHC.Base.$dm>>{v rjw}’),
     (rjx, Identifier ‛base:GHC.Base.$dmfail{v rjx}’),
     (rjz, Identifier ‛base:GHC.Base.D:Monad{v rjz}’)]

comment:2 Changed 6 years ago by leroux

Try compiling with integer-simple instead of integer-gmp.

Add to mk/build.mk:

INTEGER_LIBRARY = integer-simple

comment:3 Changed 6 years ago by schyler

Related, but for x86 not arm; getting this even after pulling new tree -

ghc-stage1.exe: panic! (the 'impossible' happened)
  (GHC version 7.7.20130922 for i386-unknown-mingw32):
        tcIfaceGlobal (local): not found:
    base:Control.Applicative.$fApplicativeWrappedMonad{v rg}
    [(0c7, Identifier `base:Control.Applicative.<*>{v 0c7}'),
     (0c8, Identifier `base:Control.Applicative.pure{v 0c8}'),
     (0c9, Class `base:Control.Applicative.Alternative{tc 0c9}'),
     (2y, Class `base:Control.Applicative.Applicative{tc 2y}'),
     (rC,
      Data constructor `base:Control.Applicative.D:Alternative{d rC}'),
     (r1Z,
      Coercion axiom `base:Control.Applicative.NTCo:ZipList{tc r1Z}'),
     (r34,
      Coercion axiom `base:Control.Applicative.NTCo:Const{tc r34}'),
     (r3y,
      Coercion axiom `base:Control.Applicative.NTCo:WrappedMonad{tc r3y}'),
     (r3E,
      Coercion axiom `base:Control.Applicative.NTCo:WrappedArrow{tc r3E}'),
     (r4f,
      Data constructor `base:Control.Applicative.D:Applicative{d r4f}'),
     (r4r, Identifier `base:Control.Applicative.$p1Applicative{v r4r}'),
     (r4s, Identifier `base:Control.Applicative.$p1Alternative{v r4s}'),
     (r4w, Identifier `base:Control.Applicative.getZipList{v r4w}'),
     (r4x, Data constructor `base:Control.Applicative.ZipList{d r4x}'),
     (r4y, Type constructor `base:Control.Applicative.ZipList{tc r4y}'),
     (r4z, Identifier `base:Control.Applicative.unwrapMonad{v r4z}'),
     (r4A,
      Data constructor `base:Control.Applicative.WrapMonad{d r4A}'),
     (r4B,
      Type constructor `base:Control.Applicative.WrappedMonad{tc r4B}'),
     (r4C, Identifier `base:Control.Applicative.unwrapArrow{v r4C}'),
     (r4D,
      Data constructor `base:Control.Applicative.WrapArrow{d r4D}'),
     (r4E,
      Type constructor `base:Control.Applicative.WrappedArrow{tc r4E}'),
     (r4F, Identifier `base:Control.Applicative.getConst{v r4F}'),
     (r4G, Data constructor `base:Control.Applicative.Const{d r4G}'),
     (r4H, Type constructor `base:Control.Applicative.Const{tc r4H}'),
     (r4I, Identifier `base:Control.Applicative.<*{v r4I}'),
     (r4J, Identifier `base:Control.Applicative.*>{v r4J}'),
     (r4K, Identifier `base:Control.Applicative.some{v r4K}'),
     (r4L, Identifier `base:Control.Applicative.many{v r4L}'),
     (r4M, Identifier `base:Control.Applicative.empty{v r4M}'),
     (r4N, Identifier `base:Control.Applicative.<|>{v r4N}'),
     (r1Et, Identifier `base:Control.Applicative.Const{v r1Et}'),
     (r1EU, Identifier `base:Control.Applicative.WrapArrow{v r1EU}'),
     (r1Ff, Identifier `base:Control.Applicative.WrapMonad{v r1Ff}'),
     (r1Fs, Identifier `base:Control.Applicative.ZipList{v r1Fs}'),
     (r1GL, Identifier `base:Control.Applicative.$dm*>{v r1GL}'),
     (r1GM, Identifier `base:Control.Applicative.$dm<*{v r1GM}'),
     (r1GO,
      Identifier `base:Control.Applicative.D:Applicative{v r1GO}'),
     (r1HI, Identifier `base:Control.Applicative.$dmsome{v r1HI}'),
     (r1HJ, Identifier `base:Control.Applicative.$dmmany{v r1HJ}'),
     (r1HL,
      Identifier `base:Control.Applicative.D:Alternative{v r1HL}')]

Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug

make[1]: *** [libraries/base/dist-install/build/Control/Applicative.o] Error 1
make: *** [all] Error 2

comment:4 Changed 6 years ago by simonpj

Description: modified (diff)

comment:5 Changed 6 years ago by simonpj

There's clearly something wrong here, but we need to be able to reproduce it repeatably. Can anyone figure out how to do that?

Simon

comment:6 Changed 6 years ago by bgamari

Not yet, I'm currently waiting on the machine that was failing to finish a build after doing a thorough cleaning. So far it hasn't failed despite being quite far through the build.

On related note, a build of 0481e076f3cb4010894324cac71e947c6637805a on an x86_64 machine has finished successfully. All-in-all, it's clear that this issue isn't terribly reproducible.

comment:7 Changed 6 years ago by bgamari

The machine that was previously failing has successfully finished its built after a distclean and sync-all.

comment:8 Changed 6 years ago by schyler

A distclean also solved it for me.

comment:9 Changed 6 years ago by bgamari

Resolution: invalid
Status: newclosed

comment:10 Changed 6 years ago by leroux

Component: CompilerBuild System
Priority: normalhigh
Resolution: invalid
Status: closednew

Error

ghc-stage1: panic! (the 'impossible' happened)
  (GHC version 7.7.20130928 for x86_64-apple-darwin):
	tcIfaceGlobal (local): not found:
    base:GHC.Base.$fMonadIO{v r1}
    [(02K, Identifier ‛base:GHC.Base.fail{v 02K}’),
     (02L, Identifier ‛base:GHC.Base.>>={v 02L}’),
     (02M, Identifier ‛base:GHC.Base.>>{v 02M}’),
     (02N, Identifier ‛base:GHC.Base.fmap{v 02N}’),
     (02O, Identifier ‛base:GHC.Base.return{v 02O}’),
     (28, Class ‛base:GHC.Base.Monad{tc 28}’),
     (2a, Class ‛base:GHC.Base.Functor{tc 2a}’),
     (36r, Type constructor ‛base:GHC.Base.Opaque{tc 36r}’),
     (36u, Type constructor ‛base:GHC.Base.String{tc 36u}’),
     (rx, Data constructor ‛base:GHC.Base.O{d rx}’),
     (ry, Identifier ‛base:GHC.Base.<${v ry}’),
     (rhK, Identifier ‛base:GHC.Base.O{v rhK}’),
     (ri0, Data constructor ‛base:GHC.Base.D:Functor{d ri0}’),
     (rio, Identifier ‛base:GHC.Base.$dm<${v rio}’),
     (riq, Identifier ‛base:GHC.Base.D:Functor{v riq}’),
     (riS, Data constructor ‛base:GHC.Base.D:Monad{d riS}’),
     (rjr, Identifier ‛base:GHC.Base.$dm>>{v rjr}’),
     (rjs, Identifier ‛base:GHC.Base.$dmfail{v rjs}’),
     (rju, Identifier ‛base:GHC.Base.D:Monad{v rju}’)]


To reproduce

cd ghc-local
perl boot; ./configure; make

cd ..
cp -Rv ghc-local ghc-clone
cd ghc-clone

make

# error should occur

Also, why does everything rebuild even though they were already built before? Path issues or make just can't detect it that way?

comment:11 Changed 6 years ago by rwbarton

make uses file modification timestamps to determine what needs to be rebuilt, and your cp command doesn't preserve timestamps, so effectively you are touching all the files in a somewhat random order.

These panics look similar to the ones in #3103, in case that helps anyone understand what is going on.

comment:12 Changed 6 years ago by simonpj

I'm afraid leroux's "to reproduce" steps didn't work for me.

Even if all the timestamps get mixed up, that should simply cause more to get recompiled.

However, fact that the complaint is about $fMonadIO, which is defined in base, but it occurs when compiling integer-gmp (which does not depend on base) makes me think that this might be another manifestation of #8320, which I fixed this morning. So things may now be good.

So, if you've been experiencing this bug, can you try again. If you get it, please help us reproduce it. Thanks!

Simon

comment:13 Changed 6 years ago by nomeata

I occasionally have that as well; right now in library/base:

  HC [stage 1] libraries/base/dist-install/build/Control/Applicative.o
ghc-stage1: panic! (the 'impossible' happened)
  (GHC version 7.9.20140129 for x86_64-unknown-linux):
        tcIfaceGlobal (local): not found:
    base:Control.Applicative.$fApplicativeWrappedMonad{v ri}
    [(0c7, Identifier ‛base:Control.Applicative.<*>{v 0c7}’),
     (0c8, Identifier ‛base:Control.Applicative.pure{v 0c8}’),
     (0c9, Class ‛base:Control.Applicative.Alternative{tc 0c9}’),
...

Thorough cleaning helps. Sorry, no further clues.

comment:14 Changed 6 years ago by nomeata

Thorough cleaning helps. Sorry, no further clues.

Had it again. Just cleaning base helps a well, which is at least faster.

comment:15 Changed 6 years ago by kgardas

Got the same issue like nomeata, but on i386-unknown-solaris platform while trying to compile HEAD.

comment:16 in reply to:  15 Changed 6 years ago by kgardas

Replying to kgardas:

Got the same issue like nomeata, but on i386-unknown-solaris platform while trying to compile HEAD.

Just to let you know: make distclean solved that for me.

comment:17 Changed 6 years ago by simonpj

So far we are stuck with this because cannot reproduce.

comment:18 Changed 6 years ago by maeder

Is this maybe related to reading files? (see https://ghc.haskell.org/trac/ghc/ticket/5013#comment:24)

comment:19 in reply to:  18 Changed 6 years ago by maeder

Replying to maeder:

Is this maybe related to reading files? (see https://ghc.haskell.org/trac/ghc/ticket/5013#comment:24)

It is not related, because simply re-compiling solved the other issue, whereas this issue can be reproduced if the tree is not cleaned.

comment:20 in reply to:  13 Changed 6 years ago by bernalex

Hi guys. I'm a complete newbie to GHC, and even Haskell still, so keep that in mind. The best (and certainly most fun) way for me to familiarise myself with the GHC code base was to dive right in. So I was hacking on base for fun and encountered an odd bug, and christiaanb in #ghc pointed me here.

Replying to nomeata:

I occasionally have that as well; right now in library/base:

  HC [stage 1] libraries/base/dist-install/build/Control/Applicative.o
ghc-stage1: panic! (the 'impossible' happened)
  (GHC version 7.9.20140129 for x86_64-unknown-linux):
        tcIfaceGlobal (local): not found:
    base:Control.Applicative.$fApplicativeWrappedMonad{v ri}
    [(0c7, Identifier ‛base:Control.Applicative.<*>{v 0c7}’),
     (0c8, Identifier ‛base:Control.Applicative.pure{v 0c8}’),
     (0c9, Class ‛base:Control.Applicative.Alternative{tc 0c9}’),
...

Thorough cleaning helps. Sorry, no further clues.

I get this:

ghc-stage1: panic! (the 'impossible' happened)
  (GHC version 7.9.20140225 for x86_64-unknown-linux):
	tcIfaceGlobal (local): not found:
    base:Control.Applicative.$fApplicativeWrappedMonad{v ri}
    [(0c7, Identifier ‘base:Control.Applicative.<*>{v 0c7}’),
     (0c8, Identifier ‘base:Control.Applicative.pure{v 0c8}’),
     (0c9, Class ‘base:Control.Applicative.Alternative{tc 0c9}’),
     (2y, Class ‘base:Control.Applicative.Applicative{tc 2y}’),
     (rE,
      Data constructor ‘base:Control.Applicative.D:Alternative{d rE}’),
     (r1J,
      Coercion axiom ‘base:Control.Applicative.NTCo:ZipList{tc r1J}’),
     (r2K,
      Coercion axiom ‘base:Control.Applicative.NTCo:Const{tc r2K}’),
     (r3c,
      Coercion axiom ‘base:Control.Applicative.NTCo:WrappedMonad{tc r3c}’),
     (r3i,
      Coercion axiom ‘base:Control.Applicative.NTCo:WrappedArrow{tc r3i}’),
     (r3T,
      Data constructor ‘base:Control.Applicative.D:Applicative{d r3T}’),
     (r45, Identifier ‘base:Control.Applicative.$p1Applicative{v r45}’),
     (r46, Identifier ‘base:Control.Applicative.$p1Alternative{v r46}’),
     (r4a, Identifier ‘base:Control.Applicative.getZipList{v r4a}’),
     (r4b, Data constructor ‘base:Control.Applicative.ZipList{d r4b}’),
     (r4c, Type constructor ‘base:Control.Applicative.ZipList{tc r4c}’),
     (r4d, Identifier ‘base:Control.Applicative.unwrapMonad{v r4d}’),
     (r4e,
      Data constructor ‘base:Control.Applicative.WrapMonad{d r4e}’),
     (r4f,
      Type constructor ‘base:Control.Applicative.WrappedMonad{tc r4f}’),
     (r4g, Identifier ‘base:Control.Applicative.unwrapArrow{v r4g}’),
     (r4h,
      Data constructor ‘base:Control.Applicative.WrapArrow{d r4h}’),
     (r4i,
      Type constructor ‘base:Control.Applicative.WrappedArrow{tc r4i}’),
     (r4j, Identifier ‘base:Control.Applicative.getConst{v r4j}’),
     (r4k, Data constructor ‘base:Control.Applicative.Const{d r4k}’),
     (r4l, Type constructor ‘base:Control.Applicative.Const{tc r4l}’),
     (r4m, Identifier ‘base:Control.Applicative.<*{v r4m}’),
     (r4n, Identifier ‘base:Control.Applicative.*>{v r4n}’),
     (r4o, Identifier ‘base:Control.Applicative.some{v r4o}’),
     (r4p, Identifier ‘base:Control.Applicative.many{v r4p}’),
     (r4q, Identifier ‘base:Control.Applicative.empty{v r4q}’),
     (r4r, Identifier ‘base:Control.Applicative.<|>{v r4r}’),
     (r1BR, Identifier ‘base:Control.Applicative.Const{v r1BR}’),
     (r1Cf, Identifier ‘base:Control.Applicative.WrapArrow{v r1Cf}’),
     (r1CD, Identifier ‘base:Control.Applicative.WrapMonad{v r1CD}’),
     (r1CT, Identifier ‘base:Control.Applicative.ZipList{v r1CT}’),
     (r1Da, Identifier ‘base:Control.Applicative.$dm*>{v r1Da}’),
     (r1DL, Identifier ‘base:Control.Applicative.$dm<*{v r1DL}’),
     (r1DN,
      Identifier ‘base:Control.Applicative.D:Applicative{v r1DN}’),
     (r1DO, Identifier ‘base:Control.Applicative.$dmsome{v r1DO}’),
     (r1EP, Identifier ‘base:Control.Applicative.$dmmany{v r1EP}’),
     (r1ER,
      Identifier ‘base:Control.Applicative.D:Alternative{v r1ER}’)]

Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug

make[1]: *** [libraries/base/dist-install/build/Control/Applicative.o] Error 1
make: *** [all_libraries/base] Error 2

It's been consistent for me. What I've been doing is applying patches to base, and then I want to rebuild it as cheaply as possible. Reading the build guides I came up with several things to try. I have tried the following (some of them might be entirely equivalent):

make # in the base directory
make all_libraries/base
make FAST=YES

Cleaning does, as mentioned, help. Failing to derive a logical solution, I went with the "engineer's approach" and simply did:

rm libraries/base/dist-install/build/Control/Applicative.*
rm libraries/base/dist-install/build/Data/List_* -R
rm libraries/base/dist-install/build/Prelude* -R
make FAST=YES

This was an attempt at just throwing out offenders and observing the results. This seemed to work nicely (i.e. make FAST=YES succeeded without errors), however make install failed with the same error as above. A regular make clean && make && make install worked nicely though.

I would be happy to assist in trying to arrive at a predictable method of reproducing this problem.

Some information on what I am using:

ghc 018676c7f883886b388652c913c99a10d2591b0b
base eea1b6f5fe254b249acc618ef5a82c3e52a27f8c (+ 2 of my patches -- rebuilding failed for both)
Linux hackintosh 3.13.3-gentoo #10 SMP Sat Feb 15 11:17:38 CET 2014 x86_64 Intel(R) Core(TM) i7-4558U CPU @ 2.80GHz GenuineIntel GNU/Linux
automake 1.13.4
autoconf-2.69

If other information would be pertinent, please let me know and I will post it.

comment:21 Changed 6 years ago by simonpj

Is it possible that you could reproduce your steps, in a fresh repo, and reproduce the crash. That is, can you give us a recipe for making it happen? That would be really useful.

Simon

comment:22 Changed 6 years ago by bernalex

cd ~/git
git clone git://github.com/ghc/ghc.git ghc2
cd ghc2
./sync-all pull
./sync-all get
perl boot
./configure --prefix=/home/alexander/tmp/ghc
make -j5
cd libraries/base/
git am ~/git/ghc/libraries/base/0001-Implement-nand-nor-nany-and-nall-in-Data.List.patch
make
Last edited 6 years ago by bernalex (previous) (diff)

comment:23 Changed 6 years ago by simonpj

Thanks for the recipe.

Alas, it works fine for me, when I tried with HEAD. I followed those exact steps, except that you didn't supply the patch to use in the second-last file, so I just modified Data.List by adding and exporting a couple of new functions. (I suppose it is just about possible that the exact patch is important.)

Then when I typed make (still in libraries/base) it re-built the base-library just fine.

NB: I did not add build.mk because that's not in the recipe above.

This is all on Linux. What architecture are you on? Does it reproduce for you on Linux?

The first few lines of output after the final make look like this. Same for you?

simonpj@cam-05-unx:~/code/ghc-8374/libraries/base$ make
make -C ../.. all_libraries/base libraries/base_dist_NO_BUILD_DEPS=YES libraries/base_dist-boot_NO_BUILD_DEPS=YES libraries/base_dist-install_NO_BUILD_DEPS=YES NO_GENERATED_MAKEFILE_RULES=YES OMIT_PHASE_0=YES OMIT_PHASE_1=YES stage=0
make[1]: Entering directory `/home/simonpj/code/ghc-8374'
===--- building final phase
make -r --no-print-directory -f ghc.mk phase=final all_libraries/base
"inplace/bin/ghc-stage1" -hisuf hi -osuf  o -hcsuf hc -static  -H32m -O    -package-name base-4.7.0.0 -hide-all-packages -i -ilibraries/base/. -ilibraries/base/dist-install/build -ilibraries/base/dist-install/build/autogen -Ilibraries/base/dist-install/build -Ilibraries/base/dist-install/build/autogen -Ilibraries/base/include   -optP-DOPTIMISE_INTEGER_GCD_LCM -optP-include -optPlibraries/base/dist-install/build/autogen/cabal_macros.h -package ghc-prim-0.3.1.0 -package integer-gmp-0.5.1.0 -package rts-1.0 -package-name base -XHaskell2010 -O2  -no-user-package-db -rtsopts      -odir libraries/base/dist-install/build -hidir libraries/base/dist-install/build -stubdir libraries/base/dist-install/build -split-objs -dynamic-too -c libraries/base/./Data/List.hs -o libraries/base/dist-install/build/Data/List.o -dyno libraries/base/dist-install/build/Data/List.dyn_o
"inplace/bin/ghc-stage1" -hisuf hi -osuf  o -hcsuf hc -static  -H32m -O    -package-name base-4.7.0.0 -hide-all-packages -i -ilibraries/base/. -ilibraries/base/dist-install/build -ilibraries/base/dist-install/build/autogen -Ilibraries/base/dist-install/build -Ilibraries/base/dist-install/build/autogen -Ilibraries/base/include   -optP-DOPTIMISE_INTEGER_GCD_LCM -optP-include -optPlibraries/base/dist-install/build/autogen/cabal_macros.h -package ghc-prim-0.3.1.0 -package integer-gmp-0.5.1.0 -package rts-1.0 -package-name base -XHaskell2010 -O2  -no-user-package-db -rtsopts      -odir libraries/base/dist-install/build -hidir libraries/base/dist-install/build -stubdir libraries/base/dist-install/build -split-objs -dynamic-too -c libraries/base/./Foreign/Marshal/Pool.hs -o libraries/base/dist-install/build/Foreign/Marshal/Pool.o -dyno libraries/base/dist-install/build/Foreign/Marshal/Pool.dyn_o

comment:24 Changed 6 years ago by bernalex

The patch is available here: <http://www.haskell.org/pipermail/libraries/2014-February/022243.html>.

I did not add build.mk either.

I posted my architecture in comment 20: <https://ghc.haskell.org/trac/ghc/ticket/8374#comment:20>:

https://ghc.haskell.org/trac/ghc/ticket/8374#comment:20

Here's the head of my make output:

make -C ../.. all_libraries/base 
make[1]: Entering directory `/home/alexander/git/ghc2'
===--- building phase 0
make -r --no-print-directory -f ghc.mk phase=0 phase_0_builds
make[2]: Nothing to be done for `phase_0_builds'.
===--- building phase 1
make -r --no-print-directory -f ghc.mk phase=1 phase_1_builds
make[2]: Nothing to be done for `phase_1_builds'.
===--- building final phase
make -r --no-print-directory -f ghc.mk phase=final all_libraries/base
"rm" -f libraries/base/dist-install/build/.depend-v-p-dyn.haskell.tmp  

I have uploaded the entire build log for you at: <https://secure.plaimi.net/~alexander/tmp/ghc-bork.log>.

comment:25 Changed 6 years ago by simonpj

Since I can't reproduce this, can you try some experiments for me?

  • Once the crash happens, copy/paste and re-run the last command line of the log. In the log you uploaded in comment 24, this was
    "inplace/bin/ghc-stage1" -hisuf hi -osuf  o -hcsuf hc -static  -H32m -O    -package-name base-4.7.0.0 -hide-all-packages -i -ilibraries/base/. -ilibraries/base/dist-install/build -ilibraries/base/dist-install/build/autogen -Ilibraries/base/dist-install/build -Ilibraries/base/dist-install/build/autogen -Ilibraries/base/include   -optP-DOPTIMISE_INTEGER_GCD_LCM -optP-include -optPlibraries/base/dist-install/build/autogen/cabal_macros.h -package ghc-prim-0.3.1.0 -package integer-gmp-0.5.1.0 -package rts-1.0 -package-name base -XHaskell2010 -O2  -no-user-package-db -rtsopts      -odir libraries/base/dist-install/build -hidir libraries/base/dist-install/build -stubdir libraries/base/dist-install/build -split-objs -dynamic-too -c libraries/base/./Control/Applicative.hs -o libraries/base/dist-install/build/Control/Applicative.o -dyno libraries/base/dist-install/build/Control/Applicative.dyn_o
    
    Does re-running that one line crash in the same way? I hope so!
  • Re-run that same command again, this time adding -ddump-if-trace to the end of the command line, and upload the result.
  • Does libraries/base/dist-install/build/Control/Applicative.hi exist? Do an ls -l on that directory so we can see the timestamps.

Thanks

Simon

comment:27 Changed 6 years ago by simonpj

Interesting

  • Can you add -ddump-tc-trace -dppr-debug?
  • Can you try with -fno-warn-amp?

Thanks

Simon

comment:28 Changed 6 years ago by bernalex

Hm. OK, this is interesting. Running with --dump-tc-trace -dppr-debug gives this: https://secure.plaimi.net/~alexander/tmp/ghc-bork-if-tc-debug.log

If I now try to run with -fno-warn-amp, or indeed without any additional arguments at all, this happens:

$ "inplace/bin/ghc-stage1" -hisuf hi -osuf  o -hcsuf hc -static  -H32m -O    -package-name base-4.7.0.0 -hide-all-packages -i -ilibraries/base/. -ilibraries/base/dist-install/build -ilibraries/base/dist-install/build/autogen -Ilibraries/base/dist-install/build -Ilibraries/base/dist-install/build/autogen -Ilibraries/base/include   -optP-DOPTIMISE_INTEGER_GCD_LCM -optP-include -optPlibraries/base/dist-install/build/autogen/cabal_macros.h -package ghc-prim-0.3.1.0 -package integer-gmp-0.5.1.0 -package rts-1.0 -package-name base -XHaskell2010 -O2  -no-user-package-db -rtsopts      -odir libraries/base/dist-install/build -hidir libraries/base/dist-install/build -stubdir libraries/base/dist-install/build -split-objs -dynamic-too -c libraries/base/./Control/Applicative.hs -o libraries/base/dist-install/build/Control/Applicative.o -dyno libraries/base/dist-install/build/Control/Applicative.dyn_o  -fno-warn-amp 
compilation IS NOT required

comment:29 Changed 6 years ago by simonpj

Can you just try from scratch with -fno-warm-amp? I think that'll cure it.

Simon

comment:30 Changed 6 years ago by simonpj

Owner: set to thoughtpolice

Just to amplify, the AMP warnings are switched off when -XNoImplicitPrelude is on, for reasons described in Note [No AMP warning with NoImplicitPrelude]. That means that Control.Applicative, and everything that might be compiled before it (ie that does not depend on it) should really be compiled with -XNoImplicitPrelude. But that is not the case, and I believe that's what is causing the trouble.

Once we've verified that this is indeed the source of the trouble (comment 29) I suppose we can either

  • Do nothing, on the grounds that the entire AMP-warning stuff is going away in 7.9, once Applicative is a superclass of Monad.
  • Change the test to be "-XNoImplicitPrelucde or part of package base".
  • Ensure that base is compiled with -fno-warn-amp.

The latter is probably the easiest, because it can be done by modifying base.cabal. Not a good long term fix, but the whole thing is only relevant to 7.8.

I'm transferring ownership to Austin.

Simon

comment:31 in reply to:  29 Changed 6 years ago by bernalex

Replying to simonpj:

Can you just try from scratch with -fno-warm-amp? I think that'll cure it.

Could you be more specific? What scratch? In base? What command? Thanks.

comment:32 Changed 6 years ago by goldfire

Having just tripped across this, adding -fno-warn-amp to the GhcLibHcOpts line in the active section of your build.mk works nicely.

comment:33 Changed 5 years ago by thoughtpolice

Milestone: 7.10.1

comment:34 Changed 5 years ago by thomie

Architecture: armUnknown/Multiple
Resolution: fixed
Status: newclosed

I reproduced the error that bernalex mentioned using the steps from comment:22 and the patch from comment:24, using the 7.8.1 source code.

Adding '-fno-warn-amp' to GhcLibHcsOpt made the problem go away.

Since the problem does not occur with master, supposedly since Applicative is now a superclass of Monad, I am closing this ticket as fixed.

comment:35 Changed 11 months ago by bgamari

Component: Build SystemBuild System (make)

The new Hadrian build system has been merged. Relabeling the tickets concerning the legacy make build system to prevent confusion.

Note: See TracTickets for help on using tickets.