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. Thanks, -Ryan On Mon, Apr 8, 2013 at 10:57 AM, GHC wrote:

#7820: Installing profiling library BREAKS non-profiling executable

--------------------------+------------------------------------------------- Reporter: rrnewton | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.6.2 | Keywords: profiling Os: Linux | Architecture: x86_64 (amd64) Failure: Runtime crash | Blockedby: Blocking: | Related:

--------------------------+------------------------------------------------- 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:

https://github.com/rrnewton/haskell-lockfree- queue/tree/5d990fe43a983fc5ed32c3f58cb2e59df71b00b6/AtomicPrimops

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)

-- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7820 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler