<div dir="ltr">By the way, does anyone have a positive example of a package on hackage that (1) uses foreign primops and (2) is robust across a wide variety of platforms and build methods? It would be great to work from such an example.<div>
<br></div><div style>Thanks,</div><div style> -Ryan</div><div style><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Apr 8, 2013 at 10:57 AM, GHC <span dir="ltr"><<a href="mailto:cvs-ghc@haskell.org" target="_blank">cvs-ghc@haskell.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">#7820: Installing profiling library BREAKS non-profiling executable<br>
--------------------------+-------------------------------------------------<br>
Reporter: rrnewton | Owner:<br>
Type: bug | Status: new<br>
Priority: normal | Component: Compiler<br>
Version: 7.6.2 | Keywords: profiling<br>
Os: Linux | Architecture: x86_64 (amd64)<br>
Failure: Runtime crash | Blockedby:<br>
Blocking: | Related:<br>
--------------------------+-------------------------------------------------<br>
I am trying to work through problems with different GHC "ways" so that I<br>
can broadly deploy a library of foreign primops for lockfree data<br>
structures. Here's the package I am testing at the moment:<br>
<br>
<a href="https://github.com/rrnewton/haskell-lockfree-" target="_blank">https://github.com/rrnewton/haskell-lockfree-</a><br>
queue/tree/5d990fe43a983fc5ed32c3f58cb2e59df71b00b6/AtomicPrimops<br>
<br>
Here is a recipe for reproducing the bug from within that directory. Both<br>
of these build modes work FINE:<br>
<br>
(cabal install --enable-library-profiling; cd testing; make prof;<br>
./Test_prof.exe)<br>
(cabal install --disable-library-profiling; cd testing; make;<br>
./Test_threaded.exe)<br>
<br>
That is, building both library and executable with profiling, or without<br>
profiling, works fine. But then this creates an executable that<br>
segfaults:<br>
<br>
(cabal install --enable-library-profiling; cd testing; make;<br>
./Test_threaded.exe)<br>
<br>
At runtime the call to the .cmm-defined foreign primop just returns zero,<br>
and then the process segfaults when it tries to use that as a Haskell<br>
value.<br>
<br>
But my understanding is that --enable-library-profiling should just add<br>
extra binaries to .cabal and NOT change the behavior of the non-profiling<br>
binaries.<br>
<br>
Yet I can confirm that I see slightly different binary sizes with the non-<br>
profiling .o and .a files installed in ~/.cabal/lib depending on whether<br>
--enable-library-profiling is activated. Perhaps this in itself is a<br>
cabal bug, but I haven't tracked down exactly what the difference is yet.<br>
<br>
I have confirmed the above behavior under:<br>
* Mac OS (ghc 7.4.2 and 7.6.2)<br>
* Linux, RHEL 6 (ghc 7.4.2 and 7.6.2)<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Ticket URL: <<a href="http://hackage.haskell.org/trac/ghc/ticket/7820" target="_blank">http://hackage.haskell.org/trac/ghc/ticket/7820</a>><br>
GHC <<a href="http://www.haskell.org/ghc/" target="_blank">http://www.haskell.org/ghc/</a>><br>
The Glasgow Haskell Compiler<br>
</font></span></blockquote></div><br></div>