Strange `ld` errors when running `stack test --coverage` on stack #614

Closed
mgsloan opened this Issue Jul 16, 2015 · 11 comments

Projects

None yet

7 participants

@mgsloan
Collaborator
mgsloan commented Jul 16, 2015

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!
@borsboom borsboom added this to the 0.2.0.0 milestone Jul 21, 2015
@mgsloan mgsloan was assigned by snoyberg Aug 6, 2015
@snoyberg
Contributor
snoyberg commented Aug 6, 2015

@mgsloan What's the plan for this?

@mgsloan
Collaborator
mgsloan commented Aug 7, 2015

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
Contributor
drwebb commented Aug 7, 2015

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
Collaborator
mgsloan commented Aug 7, 2015

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
Contributor
snoyberg commented Aug 7, 2015

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
Contributor
drwebb commented Aug 7, 2015

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

@snoyberg snoyberg added the in progress label Aug 7, 2015
@mgsloan
Collaborator
mgsloan commented Aug 7, 2015

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..

@mgsloan mgsloan closed this Aug 7, 2015
@snoyberg snoyberg removed the in progress label Aug 7, 2015
@drwebb
Contributor
drwebb commented Aug 9, 2015

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
Mokosha commented Mar 26, 2016

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

@JustusAdam
JustusAdam commented Jul 18, 2016 edited

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
Contributor
dkasak commented Aug 9, 2016 edited

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment