Installing profiling library BREAKS non-profiling executable
I am trying to work through problems with different GHC "ways" so that I can broadly deploy a library of foreign primops for lockfree data structures. Here's the package I am testing at the moment:
Here is a recipe for reproducing the bug from within that directory. Both of these build modes work FINE:
(cabal install --enable-library-profiling; cd testing; make prof; ./Test_prof.exe)
(cabal install --disable-library-profiling; cd testing; make; ./Test_threaded.exe)
That is, building both library and executable with profiling, or without profiling, works fine. But then this creates an executable that segfaults:
(cabal install --enable-library-profiling; cd testing; make; ./Test_threaded.exe)
At runtime the call to the .cmm-defined foreign primop just returns zero, and then the process segfaults when it tries to use that as a Haskell value.
But my understanding is that --enable-library-profiling should just add extra binaries to .cabal and NOT change the behavior of the non-profiling binaries.
Yet I can confirm that I see slightly different binary sizes with the non-profiling .o and .a files installed in ~/.cabal/lib depending on whether --enable-library-profiling is activated. Perhaps this in itself is a cabal bug, but I haven't tracked down exactly what the difference is yet.
I have confirmed the above behavior under:
- Mac OS (ghc 7.4.2 and 7.6.2)
- Linux, RHEL 6 (ghc 7.4.2 and 7.6.2)
Trac metadata
Trac field | Value |
---|---|
Version | 7.6.2 |
Type | Bug |
TypeOfFailure | OtherFailure |
Priority | normal |
Resolution | Unresolved |
Component | Compiler |
Test case | |
Differential revisions | |
BlockedBy | |
Related | |
Blocking | |
CC | |
Operating system | |
Architecture |