odd GHC 6.8.2 compile failure
linking the compiled stage2 failed when bootstrapping from 6.6.1, with --prefix=$HOME . It's odd because I previously had a 6.8.2 (official x86 Linux bin-dist) installed as root (it's gone now), and I still have a bunch of cabal/hackage packages installed in $HOME that were compiled by that 6.8.2 (in addition to a few things installed by `cabal install` in ~/.cabal/). Do you think that could be confusing the build process, and if it is, is that a bug - and a bug in what? ... make[3]: Leaving directory `/Users/me/programming/cabalz/NotActuallyCabalButMaybeShouldBe/ghc-6.8.2/compiler' make -f Makefile.ghcbin -wr HS_PROG=stage2/ghc-6.8.2 stage2/ghc-6.8.2 make[3]: Entering directory `/Users/me/programming/cabalz/NotActuallyCabalButMaybeShouldBe/ghc-6.8.2/compiler' ../compiler/stage1/ghc-inplace -H16m -O -package ghc -Istage2 -cpp -fglasgow-exts -fno-generics -Rghc-timing -I. -IcodeGen -InativeGen -Iparser -Rghc-timing -DGHCI -threaded -fforce-recomp -c main/Main.hs -o stage2/main/Main.o -ohi stage2/main/Main.hi <<ghc: 293758172 bytes, 332 GCs, 8590865/18490044 avg/max bytes residency (5 samples), 42M in use, 0.00 INIT (0.00 elapsed), 0.83 MUT (0.91 elapsed), 0.40 GC (0.43 elapsed) :ghc>> ../compiler/stage1/ghc-inplace -o stage2/ghc-6.8.2 -H16m -O -package ghc -Istage2 -cpp -fglasgow-exts -fno-generics -Rghc-timing -I. -IcodeGen -InativeGen -Iparser -Rghc-timing -DGHCI -threaded -fforce-recomp stage2/main/Main.o /Users/me/HOME/lib/Cabal-1.2.3.0/ghc-6.8.2/libHSCabal-1.2.3.0.a(InstalledPackageInfo.o): In function `sEZA_info': (.text+0x177c4): undefined reference to `prettyzm1zi0zi0zi0_TextziPrettyPrintziHughesPJ_lvl21_closure' /Users/me/HOME/lib/Cabal-1.2.3.0/ghc-6.8.2/libHSCabal-1.2.3.0.a(InstalledPackageInfo.o): In function `sEZA_info': (.text+0x177cb): undefined reference to `prettyzm1zi0zi0zi0_TextziPrettyPrintziHughesPJ_lvl22_closure' /Users/me/HOME/lib/Cabal-1.2.3.0/ghc-6.8.2/libHSCabal-1.2.3.0.a(InstalledPackageInfo.o): In function `sF0s_info': (.text+0x17974): undefined reference to `prettyzm1zi0zi0zi0_TextziPrettyPrintziHughesPJ_lvl21_closure' /Users/me/HOME/lib/Cabal-1.2.3.0/ghc-6.8.2/libHSCabal-1.2.3.0.a(InstalledPackageInfo.o): In function `sF0s_info': (.text+0x1797b): undefined reference to `prettyzm1zi0zi0zi0_TextziPrettyPrintziHughesPJ_lvl22_closure' /Users/me/HOME/lib/Cabal-1.2.3.0/ghc-6.8.2/libHSCabal-1.2.3.0.a(Package.o): In function `shme_info': (.text+0x100d): undefined reference to `base_DataziList_zdsintersperse_info' /Users/me/HOME/lib/Cabal-1.2.3.0/ghc-6.8.2/libHSCabal-1.2.3.0.a(ParseUtils.o): In function `swtq_info': (.text+0xa879): undefined reference to `base_DataziList_zdsintersperse_info' /Users/me/HOME/lib/Cabal-1.2.3.0/ghc-6.8.2/libHSCabal-1.2.3.0.a(ParseUtils.o): In function `swtC_info': (.text+0xa999): undefined reference to `base_DataziList_zdsintersperse_info' /Users/me/HOME/lib/Cabal-1.2.3.0/ghc-6.8.2/libHSCabal-1.2.3.0.a(Version.o): In function `r7DH_info': (.text+0x27d7): undefined reference to `base_TextziParserCombinatorsziReadP_zdschoice_info' /Users/me/HOME/lib/Cabal-1.2.3.0/ghc-6.8.2/libHSCabal-1.2.3.0.a(Version.o): In function `r7DH_srt': (.data+0x454): undefined reference to `base_TextziParserCombinatorsziReadP_zdschoice_closure' collect2: ld returned 1 exit status <<ghc: 20856200 bytes, 4 GCs, 128260/128260 avg/max bytes residency (1 samples), 16M in use, 0.00 INIT (0.00 elapsed), 0.02 MUT (5.00 elapsed), 0.01 GC (0.02 elapsed) :ghc>> make[3]: *** [stage2/ghc-6.8.2] Error 1 make[3]: Leaving directory `/Users/me/programming/cabalz/NotActuallyCabalButMaybeShouldBe/ghc-6.8.2/compiler' make[2]: *** [stage2/ghc-6.8.2] Error 2 make[2]: Leaving directory `/Users/me/programming/cabalz/NotActuallyCabalButMaybeShouldBe/ghc-6.8.2/compiler' make[1]: *** [stage2] Error 2 make[1]: Leaving directory `/Users/me/programming/cabalz/NotActuallyCabalButMaybeShouldBe/ghc-6.8.2' make: *** [bootstrap2] Error 2 ~Isaac
Isaac Dupree wrote:
linking the compiled stage2 failed when bootstrapping from 6.6.1, with --prefix=$HOME .
It's odd because I previously had a 6.8.2 (official x86 Linux bin-dist) installed as root (it's gone now), and I still have a bunch of cabal/hackage packages installed in $HOME that were compiled by that 6.8.2 (in addition to a few things installed by `cabal install` in ~/.cabal/). Do you think that could be confusing the build process, and if it is, is that a bug - and a bug in what?
It looks like at some point you've updated your sources and recompiled without cleaning in stage2, or something similar. The build system doesn't currently notice when libraries have changed and stage2 needs to be completely recompiled. Cheers, Simon
... make[3]: Leaving directory `/Users/me/programming/cabalz/NotActuallyCabalButMaybeShouldBe/ghc-6.8.2/compiler'
make -f Makefile.ghcbin -wr HS_PROG=stage2/ghc-6.8.2 stage2/ghc-6.8.2 make[3]: Entering directory `/Users/me/programming/cabalz/NotActuallyCabalButMaybeShouldBe/ghc-6.8.2/compiler'
../compiler/stage1/ghc-inplace -H16m -O -package ghc -Istage2 -cpp -fglasgow-exts -fno-generics -Rghc-timing -I. -IcodeGen -InativeGen -Iparser -Rghc-timing -DGHCI -threaded -fforce-recomp -c main/Main.hs -o stage2/main/Main.o -ohi stage2/main/Main.hi <<ghc: 293758172 bytes, 332 GCs, 8590865/18490044 avg/max bytes residency (5 samples), 42M in use, 0.00 INIT (0.00 elapsed), 0.83 MUT (0.91 elapsed), 0.40 GC (0.43 elapsed) :ghc>> ../compiler/stage1/ghc-inplace -o stage2/ghc-6.8.2 -H16m -O -package ghc -Istage2 -cpp -fglasgow-exts -fno-generics -Rghc-timing -I. -IcodeGen -InativeGen -Iparser -Rghc-timing -DGHCI -threaded -fforce-recomp stage2/main/Main.o /Users/me/HOME/lib/Cabal-1.2.3.0/ghc-6.8.2/libHSCabal-1.2.3.0.a(InstalledPackageInfo.o): In function `sEZA_info': (.text+0x177c4): undefined reference to `prettyzm1zi0zi0zi0_TextziPrettyPrintziHughesPJ_lvl21_closure' /Users/me/HOME/lib/Cabal-1.2.3.0/ghc-6.8.2/libHSCabal-1.2.3.0.a(InstalledPackageInfo.o): In function `sEZA_info': (.text+0x177cb): undefined reference to `prettyzm1zi0zi0zi0_TextziPrettyPrintziHughesPJ_lvl22_closure' /Users/me/HOME/lib/Cabal-1.2.3.0/ghc-6.8.2/libHSCabal-1.2.3.0.a(InstalledPackageInfo.o): In function `sF0s_info': (.text+0x17974): undefined reference to `prettyzm1zi0zi0zi0_TextziPrettyPrintziHughesPJ_lvl21_closure' /Users/me/HOME/lib/Cabal-1.2.3.0/ghc-6.8.2/libHSCabal-1.2.3.0.a(InstalledPackageInfo.o): In function `sF0s_info': (.text+0x1797b): undefined reference to `prettyzm1zi0zi0zi0_TextziPrettyPrintziHughesPJ_lvl22_closure' /Users/me/HOME/lib/Cabal-1.2.3.0/ghc-6.8.2/libHSCabal-1.2.3.0.a(Package.o): In function `shme_info': (.text+0x100d): undefined reference to `base_DataziList_zdsintersperse_info' /Users/me/HOME/lib/Cabal-1.2.3.0/ghc-6.8.2/libHSCabal-1.2.3.0.a(ParseUtils.o): In function `swtq_info': (.text+0xa879): undefined reference to `base_DataziList_zdsintersperse_info' /Users/me/HOME/lib/Cabal-1.2.3.0/ghc-6.8.2/libHSCabal-1.2.3.0.a(ParseUtils.o): In function `swtC_info': (.text+0xa999): undefined reference to `base_DataziList_zdsintersperse_info' /Users/me/HOME/lib/Cabal-1.2.3.0/ghc-6.8.2/libHSCabal-1.2.3.0.a(Version.o): In function `r7DH_info': (.text+0x27d7): undefined reference to `base_TextziParserCombinatorsziReadP_zdschoice_info' /Users/me/HOME/lib/Cabal-1.2.3.0/ghc-6.8.2/libHSCabal-1.2.3.0.a(Version.o): In function `r7DH_srt': (.data+0x454): undefined reference to `base_TextziParserCombinatorsziReadP_zdschoice_closure' collect2: ld returned 1 exit status <<ghc: 20856200 bytes, 4 GCs, 128260/128260 avg/max bytes residency (1 samples), 16M in use, 0.00 INIT (0.00 elapsed), 0.02 MUT (5.00 elapsed), 0.01 GC (0.02 elapsed) :ghc>> make[3]: *** [stage2/ghc-6.8.2] Error 1 make[3]: Leaving directory `/Users/me/programming/cabalz/NotActuallyCabalButMaybeShouldBe/ghc-6.8.2/compiler'
make[2]: *** [stage2/ghc-6.8.2] Error 2 make[2]: Leaving directory `/Users/me/programming/cabalz/NotActuallyCabalButMaybeShouldBe/ghc-6.8.2/compiler'
make[1]: *** [stage2] Error 2 make[1]: Leaving directory `/Users/me/programming/cabalz/NotActuallyCabalButMaybeShouldBe/ghc-6.8.2' make: *** [bootstrap2] Error 2
~Isaac _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Simon Marlow wrote:
Isaac Dupree wrote:
linking the compiled stage2 failed when bootstrapping from 6.6.1, with --prefix=$HOME .
It's odd because I previously had a 6.8.2 (official x86 Linux bin-dist) installed as root (it's gone now), and I still have a bunch of cabal/hackage packages installed in $HOME that were compiled by that 6.8.2 (in addition to a few things installed by `cabal install` in ~/.cabal/). Do you think that could be confusing the build process, and if it is, is that a bug - and a bug in what?
It looks like at some point you've updated your sources and recompiled without cleaning in stage2, or something similar. The build system doesn't currently notice when libraries have changed and stage2 needs to be completely recompiled.
It sure looks that way! But I didn't do that personally; I think these are all of my steps: [download via Firefox to /Users/me/downloads/ghc-6.8.2-src.tar.bz2] cd /Users/me/programming/cabalz/NotActuallyCabalButMaybeShouldBe aunpack /Users/me/downloads/ghc-6.8.2-src.tar.bz2 # this `aunpack` is equivalent to tar -xjf in this case. cd ghc-6.8.2 ./configure --prefix=$HOME # ($HOME is /Users/me/HOME , by the way). make Indeed I just reproduced it, newly unpacking that tarball in a new location, to make sure, and I got the same error. What if GHC suddenly decided to link with the newer versions of the boot-libraries than come with 6.8.2, the ones that could be found in $HOME since I installed them there? (or with the _same_ versions that happened to be compiled with different flags, perhaps?) ~Isaac
Isaac Dupree wrote:
Simon Marlow wrote:
Isaac Dupree wrote:
linking the compiled stage2 failed when bootstrapping from 6.6.1, with --prefix=$HOME .
It's odd because I previously had a 6.8.2 (official x86 Linux bin-dist) installed as root (it's gone now), and I still have a bunch of cabal/hackage packages installed in $HOME that were compiled by that 6.8.2 (in addition to a few things installed by `cabal install` in ~/.cabal/). Do you think that could be confusing the build process, and if it is, is that a bug - and a bug in what?
It looks like at some point you've updated your sources and recompiled without cleaning in stage2, or something similar. The build system doesn't currently notice when libraries have changed and stage2 needs to be completely recompiled.
It sure looks that way! But I didn't do that personally; I think these are all of my steps: [download via Firefox to /Users/me/downloads/ghc-6.8.2-src.tar.bz2] cd /Users/me/programming/cabalz/NotActuallyCabalButMaybeShouldBe aunpack /Users/me/downloads/ghc-6.8.2-src.tar.bz2 # this `aunpack` is equivalent to tar -xjf in this case. cd ghc-6.8.2 ./configure --prefix=$HOME # ($HOME is /Users/me/HOME , by the way). make
Indeed I just reproduced it, newly unpacking that tarball in a new location, to make sure, and I got the same error.
What if GHC suddenly decided to link with the newer versions of the boot-libraries than come with 6.8.2, the ones that could be found in $HOME since I installed them there? (or with the _same_ versions that happened to be compiled with different flags, perhaps?)
And you get different results if you omit the --prefix=$HOME? (if so, that's very strange, and I don't have a clue what's wrong, yet) Cheers, Simon
Simon Marlow wrote:
Isaac Dupree wrote:
Simon Marlow wrote:
Isaac Dupree wrote:
linking the compiled stage2 failed when bootstrapping from 6.6.1, with --prefix=$HOME .
It's odd because I previously had a 6.8.2 (official x86 Linux bin-dist) installed as root (it's gone now), and I still have a bunch of cabal/hackage packages installed in $HOME that were compiled by that 6.8.2 (in addition to a few things installed by `cabal install` in ~/.cabal/). Do you think that could be confusing the build process, and if it is, is that a bug - and a bug in what?
It looks like at some point you've updated your sources and recompiled without cleaning in stage2, or something similar. The build system doesn't currently notice when libraries have changed and stage2 needs to be completely recompiled.
It sure looks that way! But I didn't do that personally; I think these are all of my steps: [download via Firefox to /Users/me/downloads/ghc-6.8.2-src.tar.bz2] cd /Users/me/programming/cabalz/NotActuallyCabalButMaybeShouldBe aunpack /Users/me/downloads/ghc-6.8.2-src.tar.bz2 # this `aunpack` is equivalent to tar -xjf in this case. cd ghc-6.8.2 ./configure --prefix=$HOME # ($HOME is /Users/me/HOME , by the way). make
Indeed I just reproduced it, newly unpacking that tarball in a new location, to make sure, and I got the same error.
What if GHC suddenly decided to link with the newer versions of the boot-libraries than come with 6.8.2, the ones that could be found in $HOME since I installed them there? (or with the _same_ versions that happened to be compiled with different flags, perhaps?)
And you get different results if you omit the --prefix=$HOME? (if so, that's very strange, and I don't have a clue what's wrong, yet)
tested a couple more times: - it still fails without --prefix=$HOME - but it succeeds if I `su - east` and have 'east' compile it (without using --prefix here either) ('east' being another user on my machine other than the user 'me' which I usually use) Isaac
Isaac Dupree wrote:
Simon Marlow wrote:
Isaac Dupree wrote:
Simon Marlow wrote:
Isaac Dupree wrote:
linking the compiled stage2 failed when bootstrapping from 6.6.1, with --prefix=$HOME .
It's odd because I previously had a 6.8.2 (official x86 Linux bin-dist) installed as root (it's gone now), and I still have a bunch of cabal/hackage packages installed in $HOME that were compiled by that 6.8.2 (in addition to a few things installed by `cabal install` in ~/.cabal/). Do you think that could be confusing the build process, and if it is, is that a bug - and a bug in what?
It looks like at some point you've updated your sources and recompiled without cleaning in stage2, or something similar. The build system doesn't currently notice when libraries have changed and stage2 needs to be completely recompiled.
It sure looks that way! But I didn't do that personally; I think these are all of my steps: [download via Firefox to /Users/me/downloads/ghc-6.8.2-src.tar.bz2] cd /Users/me/programming/cabalz/NotActuallyCabalButMaybeShouldBe aunpack /Users/me/downloads/ghc-6.8.2-src.tar.bz2 # this `aunpack` is equivalent to tar -xjf in this case. cd ghc-6.8.2 ./configure --prefix=$HOME # ($HOME is /Users/me/HOME , by the way). make
Indeed I just reproduced it, newly unpacking that tarball in a new location, to make sure, and I got the same error.
What if GHC suddenly decided to link with the newer versions of the boot-libraries than come with 6.8.2, the ones that could be found in $HOME since I installed them there? (or with the _same_ versions that happened to be compiled with different flags, perhaps?)
And you get different results if you omit the --prefix=$HOME? (if so, that's very strange, and I don't have a clue what's wrong, yet)
tested a couple more times: - it still fails without --prefix=$HOME - but it succeeds if I `su - east` and have 'east' compile it (without using --prefix here either) ('east' being another user on my machine other than the user 'me' which I usually use)
Ah, I see. You have packages installed in your home directory for GHC 6.8.2, and these are being picked up by the stage1 compiler. We should be using -no-user-package-conf when running the compiler from the build tree. I'll test this fix. Note however that if you install this compiler, the packages in your home directory won't work any more, because they were compiled by another instance of 6.8.2 against a different set of packages. Cheers, Simon
Simon Marlow wrote:
Note however that if you install this compiler, the packages in your home directory won't work any more, because they were compiled by another instance of 6.8.2
true, but doesn't 6.8.2 itself have the same ABI as any other 6.8.2, not counting packages?
against a different set of packages.
hmm. different versions? I think it might work out since I installed everything locally, if I just install the versions of the extra-libs that came with the 6.8.2 bindist... Or do I have too great hopes in the reproducibility of ghc compilations? (Not that I have any reason to try that. I would probably just pull from the 6.8-darcs-branch to get your patch (and other post-6.8.2 fixes) and recompile everything anyway.) ~Isaac
Isaac Dupree wrote:
Simon Marlow wrote:
Note however that if you install this compiler, the packages in your home directory won't work any more, because they were compiled by another instance of 6.8.2
true, but doesn't 6.8.2 itself have the same ABI as any other 6.8.2, not counting packages?
Yes, the ABI is the same, but there's no guarantee that the interfaces to all the packages are the same.
against a different set of packages.
hmm. different versions? I think it might work out since I installed everything locally, if I just install the versions of the extra-libs that came with the 6.8.2 bindist...
Or do I have too great hopes in the reproducibility of ghc compilations?
It's too fragile to rely on getting the same results when you compile a package again, if -O is on. In practice, if the conditions are exactly the same you can often get identical interfaces, but we've never put any effort into figuring out how to guarantee this and under what conditions. Better not to rely on it. Cheers, Simon
participants (2)
-
Isaac Dupree -
Simon Marlow