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 <cvs-...@haskell.org> 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 >
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs