Strange ld errors when running stack test --coverage on stack

[mgsloan]

First run I got

[37 of 61] Compiling Stack.PackageIndex ( src/Stack/PackageIndex.hs, .stack-work/dist/x86_64-linux/Cabal-1.18.1.5/build/Stack/PackageIndex.o )
/usr/bin/ld: .stack-work/dist/x86_64-linux/Cabal-1.18.1.5/build/Stack/Types/Image.dyn_o: relocation R_X86_64_PC32 against undefined symbol `_hpc_tickboxes_stackzm0zi1zi2zi1_DataziAesonziExtended_hpc' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: Bad value
collect2: error: ld returned 1 exit status

Puzzlingly, next run it got further

[40 of 61] Compiling Stack.Docker     ( src/Stack/Docker.hs, .stack-work/dist/x86_64-linux/Cabal-1.18.1.5/build/Stack/Docker.o )
/usr/bin/ld: .stack-work/dist/x86_64-linux/Cabal-1.18.1.5/build/Stack/Constants.dyn_o: relocation R_X86_64_PC32 against undefined symbol `_hpc_tickboxes_stackzm0zi1zi2zi1_StackziTypesziConfig_hpc' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: Bad value
collect2: error: ld returned 1 exit status

Then, the third run finished compilation and successfully ran the tests! Very weird.

Next actions:

1. Report or find GHC bug
2. Have test --coverage imply -fPIC, as a workaround?
3. Use static linking when doing test --coverage
4. An undesireable workaround would be to automatically rerun stack test when such an error occurs. Yuck!

[snoyberg]

@mgsloan What's the plan for this?

[mgsloan]

I think the plan for this is to report it as a GHC bug and hope that it gets fixed promptly. I haven't had luck with -fPIC or static linking.

I tried coming up with a repro involving just cabal, and I get a different issue, a GHC panic error very similar to the ones discussed in https://ghc.haskell.org/trac/ghc/ticket/10745 and https://ghc.haskell.org/trac/ghc/ticket/10665 .

I get such behavior when I do

cabal install --enable-tests --ghc-options=-fhpc

[ 4 of 64] Compiling Network.HTTP.Download.Verified ( src/Network/HTTP/Download/Verified.hs, dist/dist-sandbox-dd170747/build/Network/HTTP/Download/Verified.o )
ghc: panic! (the 'impossible' happened)
  (GHC version 7.10.2 for x86_64-unknown-linux):
    Tick in rule
  unstream
    @ a34_ajs5
    @ Void
    @ m_ajs4
    @ ()
    (ConduitWithStream
       @ a34_ajs5
       @ Void
       @ m_ajs4
       @ ()
       (sinkNullC @ a34_ajs5 @ m_ajs4 $dMonad1_ajs7 @ Void)
       (sinkNullS @ a34_ajs5 @ m_ajs4 $dMonad1_ajs7 @ Void))

It sounds like simon fixed this in ghc HEAD, 12 hours ago. Tomorrow, I will push a branch which has a travis config which runs test --coverage, and see if these issues are resolved by GHC HEAD.

It's somewhat mysterious to me why cabal-install runs into this error, whereas stack runs into the ld issue (which seems to go away if you keeping trying to build)

[drwebb]

No way! This just started on a machine that was on recent nightly resolver.
If you need more help trouble shooting I am seeing the message to compile
again with -fpic. @snoyberg you came across this before, Google the ld line
and the StaticFiles module in yesod

yesodweb/yesod#612 (comment)

@mgsloan ounds like you got it covered, good to hear it fixed in HEAD

I think the plan for this is to report it as a GHC bug and hope that it
gets fixed promptly. I haven't had luck with -fPIC or static linking.

I tried coming up with a repro involving just cabal, and I get a different
issue, a GHC panic error very similar to the ones discussed in
https://ghc.haskell.org/trac/ghc/ticket/10745 and
https://ghc.haskell.org/trac/ghc/ticket/10665 .

I get such behavior when I do

cabal install --enable-tests --ghc-options=-fhpc

[ 4 of 64] Compiling Network.HTTP.Download.Verified (
src/Network/HTTP/Download/Verified.hs,
dist/dist-sandbox-dd170747/build/Network/HTTP/Download/Verified.o )
ghc: panic! (the 'impossible' happened)
(GHC version 7.10.2 for x86_64-unknown-linux):
Tick in rule
unstream
@ a34_ajs5
@ Void
@ m_ajs4
@ ()
(ConduitWithStream
@ a34_ajs5
@ Void
@ m_ajs4
@ ()
(sinkNullC @ a34_ajs5 @ m_ajs4 $dMonad1_ajs7 @ Void)
(sinkNullS @ a34_ajs5 @ m_ajs4 $dMonad1_ajs7 @ Void))

It sounds like simon fixed this in ghc HEAD, 12 hours ago. Tomorrow, I will
push a branch which has a travis config which runs test --coverage, and see
if these issues are resolved by GHC HEAD.

—
Reply to this email directly or view it on GitHub
#614 (comment)
.

[mgsloan]

I'm merely crossing my fingers that the issue with ld is somehow related. If it's still around with HEAD, I'll create a ghc bug report about it.

[snoyberg]

My real question is: is there anything we're going to do for this at the stack level? If not, we should close this issue and move it upstream, with a note in the FAQ about the problem.

[drwebb]

@mgsloan did you test on ghc HEAD? If it's working, we should close this. I can write the FAQ entry in the wiki.

[mgsloan]

I've just pushed a test of this to a branch. Here's the build for GHC HEAD: https://travis-ci.org/commercialhaskell/stack/jobs/74637288

Looks like mono-traversable doesn't support GHC HEAD currently:

Preprocessing library mono-traversable-0.9.2.1...
[1 of 7] Compiling Data.ByteVector  ( src/Data/ByteVector.hs, dist/build/Data/ByteVector.o )
[2 of 7] Compiling Data.MonoTraversable ( src/Data/MonoTraversable.hs, dist/build/Data/MonoTraversable.o )
src/Data/MonoTraversable.hs:482:16: error:
    The INLINE pragma for ‘unsafeHead’ lacks an accompanying binding
      (The INLINE pragma must be given where ‘unsafeHead’ is declared)

@snoyberg Yeah, I think this can be closed, as there's nothing to do in stack to fix it.

@drwebb Thanks, that sounds good! Such a note should be added regardless of whether it's resolved in GHC HEAD. One thing to be sure to point out is that, oddly enough, trying to recompile over and over again is a good strategy for resolving this. The issue seems to be nondeterministic..

[drwebb]

I've added a note to the FAQ explaining this is an open issue with no known workaround, and advised using docker to build if it's a big problem. It's kind of a half-way answer, but I'm not sure of a better solution.

[Mokosha]

This problem is preventing me from deploying to heroku. :( Hopefully we will figure out the reason!

[JustusAdam]

Has there been any development on this issue upstream? If there's a ghc ticket for this it would be cool if there was a reference to it here or in the manual, because I recently stumbled across this problem too, which is now preventing me to do static compilation and when I search for the issue I alway just land here or in the manual.

If anyone has a link to an upstream ticket please post.

[dkasak]

@JustusAdam There is a ticket for a similar issue which may be related (also see the issue wedens references from). I'll add this information to the FAQ shortly.