#9012 closed bug (fixed)

HPC is broken (relocation R_386_GOTOFF against undefined symbol can not be used when making a shared object)

Reported by: Feuerbach Owned by:
Priority: high Milestone: 7.8.3
Component: Compiler Version: 7.8.2
Keywords: Cc: kini
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: None/Unknown Test Case:
Blocked By: Blocking:
Related Tickets: Differential Revisions:

Description

This happens in a clean sandbox:

% cabal install -j --enable-library-coverage logict    
Resolving dependencies...
Notice: installing into a sandbox located at
/home/feuerbach/tmp/sandboxes/smallcheck-bug/.cabal-sandbox
Configuring mtl-2.1.3.1...
Building mtl-2.1.3.1...
Installed mtl-2.1.3.1
Configuring logict-0.6.0.2...
Building logict-0.6.0.2...
Failed to install logict-0.6.0.2
Last 10 lines of the build log ( /home/feuerbach/tmp/sandboxes/smallcheck-bug/.cabal-sandbox/logs/logict-0.6.0.2.log ):
Configuring logict-0.6.0.2...
Building logict-0.6.0.2...
Preprocessing library logict-0.6.0.2...
[1 of 2] Compiling Control.Monad.Logic.Class ( Control/Monad/Logic/Class.hs, dist/dist-sandbox-cdfcc6f0/build/Control/Monad/Logic/Class.o )
[2 of 2] Compiling Control.Monad.Logic ( Control/Monad/Logic.hs, dist/dist-sandbox-cdfcc6f0/build/Control/Monad/Logic.o )
/usr/bin/ld: dist/dist-sandbox-cdfcc6f0/build/Control/Monad/Logic.dyn_o: relocation R_386_GOTOFF against undefined symbol `_hpc_tickboxes_mtlzm2zi1zi3zi1_ControlziMonadziReaderziClass_hpc' can not be used when making a shared object
/usr/bin/ld: final link failed: Bad value
collect2: error: ld returned 1 exit status
cabal: Error: some packages failed to install:
logict-0.6.0.2 failed during the building phase. The exception was:
ExitFailure 1

Attachments (1)

0001-Mark-HPC-ticks-labels-as-dynamic.patch (1.0 KB) - added by rwbarton 13 months ago.

Download all attachments as: .zip

Change History (23)

comment:1 Changed 16 months ago by Feuerbach

I can reproduce this with both 7.6.3 and 7.8.2.

comment:2 Changed 15 months ago by hvr

Maybe interesting to know, which cabal-install version was used?

comment:3 Changed 15 months ago by Feuerbach

I can reproduce this with recent cabal HEAD (84a768094, Apr 27).

comment:4 Changed 15 months ago by thoughtpolice

  • Milestone set to 7.8.3
  • Priority changed from normal to high

comment:5 Changed 14 months ago by thoughtpolice

  • Milestone changed from 7.8.3 to 7.8.4

Moving to 7.8.4.

comment:6 Changed 14 months ago by kini

  • Cc kini added

comment:7 Changed 13 months ago by rwbarton

This patch fixes building HPC dynamic libraries, at least on Linux x86_64. Note that I haven't tested whether the resulting libraries are correct in any sense.

comment:8 Changed 13 months ago by rwbarton

  • Status changed from new to patch

comment:9 Changed 13 months ago by rwbarton

I don't understand how one is supposed to actually use these HPC libraries as the .mix files don't seem to be installed anywhere by cabal. What are the people who encounter this issue actually trying to do?

I did manage to do some manual tests and noticed a difference in behavior between the static and dynamic libraries: there are more packages included in the .tix file with the dynamic libraries. I don't understand why or know whether this is a good thing or a bad thing.

comment:10 follow-up: Changed 13 months ago by Feuerbach

rwbarton: first off, thanks for working on this!

To answer your question, the typical workflow is to build the package in hpc mode (cabal install -j --enable-library-coverage myprogram), then run cabal test. It should then run the tests and generate an hpc report somewhere under dist/

comment:11 in reply to: ↑ 10 Changed 13 months ago by rwbarton

I can't seem to get cabal test to work on any package. Could you give exact instructions for building and testing (with HPC) any package of your choice?

comment:12 follow-up: Changed 13 months ago by Feuerbach

Try regex-applicative. E.g.: cabal install --enable-library-coverage --run-tests regex-applicative. (Assuming you have cabal-install 1.20.) That should build the package, run the tests, and generate the hpc report.

Obviously I can't test these instructions because of the very bug we're discussing...

comment:13 Changed 13 months ago by Feuerbach

Alternative instructions:

cabal get regex-applicative
cd regex-applicative*
cabal install --enable-library-coverage --only-dependencies --enable-tests
cabal test

comment:14 in reply to: ↑ 12 Changed 13 months ago by rwbarton

Replying to Feuerbach:

Try regex-applicative. E.g.: cabal install --enable-library-coverage --run-tests regex-applicative. (Assuming you have cabal-install 1.20.) That should build the package, run the tests, and generate the hpc report.

Obviously I can't test these instructions because of the very bug we're discussing...

Great, thanks. I did this:

cabal install --only-dep --run-tests -w $HOME/ghc/inplace/bin/ghc-stage2 regex-applicative
cabal get regex-applicative
cd regex-applicative*
cabal configure --enable-library-coverage --enable-tests -w $HOME/ghc/inplace/bin/ghc-stage2 --ghc-option=-XFlexibleContexts # see #8883
cabal test

and it seems to have worked fine:

[... building ...]
Running 1 test suites...
Test suite test-regex-applicative: RUNNING...
Test suite test-regex-applicative: PASS
Test suite logged to:
dist/test/regex-applicative-0.3.0.2-test-regex-applicative.log
Writing: regex-applicative-0.3.0.2/Text.Regex.Applicative.StateQueue.hs.html
Writing: regex-applicative-0.3.0.2/Text.Regex.Applicative.Compile.hs.html
Writing: regex-applicative-0.3.0.2/Text.Regex.Applicative.Types.hs.html
Writing: regex-applicative-0.3.0.2/Text.Regex.Applicative.Interface.hs.html
Writing: regex-applicative-0.3.0.2/Text.Regex.Applicative.Reference.hs.html
Writing: regex-applicative-0.3.0.2/Text.Regex.Applicative.Object.hs.html
Writing: hpc_index.html
Writing: hpc_index_fun.html
Writing: hpc_index_alt.html
Writing: hpc_index_exp.html
Test coverage report written to
dist/hpc/html/test-regex-applicative/hpc_index.html
1 of 1 test suites (1 of 1 test cases) passed.
Writing: regex-applicative-0.3.0.2/Text.Regex.Applicative.StateQueue.hs.html
Writing: regex-applicative-0.3.0.2/Text.Regex.Applicative.Compile.hs.html
Writing: regex-applicative-0.3.0.2/Text.Regex.Applicative.Types.hs.html
Writing: regex-applicative-0.3.0.2/Text.Regex.Applicative.Interface.hs.html
Writing: regex-applicative-0.3.0.2/Text.Regex.Applicative.Reference.hs.html
Writing: regex-applicative-0.3.0.2/Text.Regex.Applicative.Object.hs.html
Writing: hpc_index.html
Writing: hpc_index_fun.html
Writing: hpc_index_alt.html
Writing: hpc_index_exp.html
Package coverage report written to
dist/hpc/html/regex-applicative-0.3.0.2/hpc_index.html

The report looks fine, too. (I tried the your first set of instructions first, and I got the same successful messages, but as far as I can tell Cabal didn't save the coverage report anywhere!)

However, if I also install the dependencies (test frameworks) with --enable-library-coverage, then things break:

[...]
Running 1 test suites...
Test suite test-regex-applicative: RUNNING...
Test suite test-regex-applicative: PASS
Test suite logged to:
dist/test/regex-applicative-0.3.0.2-test-regex-applicative.log
hpc: can not find HUnit-1.2.5.2/Test.HUnit.Lang in ["./.hpc","./dist/hpc/mix/regex-applicative-0.3.0.2","./dist/hpc/mix/test-regex-applicative"]

The test executable is not using shared libraries at all, though, so I suspect this case has always been broken.

If I make the test executable dynamic, with the first set of steps, I get a report that includes two additional modules, Text.Regex.Applicative and Text.Regex.Applicative.Common, which have no coverage. I suspect this is due to static linking not linking those object files since they're not needed, while dynamic linking is monolithic. I also get a slightly different error with the second set of steps, possibly due to the same cause.

Changed 13 months ago by rwbarton

comment:15 Changed 13 months ago by rwbarton

This is the new patch that I'm using. My conclusion is that, at least on Linux x86_64, HPC now seems to work as well as it did before. I haven't actually tried with an older compiler though: what version is known to work?

comment:16 follow-up: Changed 13 months ago by Feuerbach

It's complicated. Older version of hpc-the-executable didn't use to play well with cabal.

OTOH, I thought I had used HPC successfully with 7.6.3, so I was surprised when I got this error.

comment:17 in reply to: ↑ 16 ; follow-up: Changed 13 months ago by rwbarton

Replying to Feuerbach:

OTOH, I thought I had used HPC successfully with 7.6.3, so I was surprised when I got this error.

Is it possible that you just weren't building dynamic libraries then, only static libraries, as it was the default for Cabal at the time? After all, the test executable is linked statically by default anyways so for the purpose of testing building the dynamic libraries is just unnecessary extra work.

comment:18 in reply to: ↑ 17 Changed 13 months ago by Feuerbach

Replying to rwbarton:

Yes, that was indeed the case. I specifically had shared: False in cabal.config until 7.8 came out.

Thus HPC probably never worked with dynamic libraries, but it wasn't noticed until recently, when dynamic libraries became necessary and widely used.

comment:19 Changed 13 months ago by Reid Barton <rwbarton@…>

In 3285a3d5bc7419464f5d2e6cef7c3adb9bca65c3/ghc:

Mark HPC ticks labels as dynamic

This enables GHC's PIC machinery for accessing tickboxes of other
packages correctly when building dynamic libraries. Previously
GHC was doing strange and wrong things in that situation. See #9012.

comment:20 Changed 13 months ago by rwbarton

  • Status changed from patch to merge

Thanks. Then I understand what is going on on the GHC side enough to be confident that this patch is correct, or at least strictly more correct than the original.

comment:21 Changed 13 months ago by thoughtpolice

  • Milestone changed from 7.8.4 to 7.8.3

comment:22 Changed 13 months ago by thoughtpolice

  • Resolution set to fixed
  • Status changed from merge to closed

Merged, thanks Reid!

Note: See TracTickets for help on using tickets.