We may be in the same boat and not realize it:  I'm trying to track down a segfault that appeared when I compiled & ran a previously working Haskell+GTK program under Fedora 18.  I think there's a bug in how GHC makes foreign import ccall "wrapper" functions. It appears to be in versions 7.4 and later.  Something is getting off by 8 bytes, and the result is a segfault when the wrapper is called.  I see that HsSyck has a bunch of these in Data/Yaml/Syck.hsc, so maybe we're seeing the same problem....?

Here's my bug report:

http://hackage.haskell.org/trac/ghc/ticket/7629



On Sun, Mar 10, 2013 at 10:28 AM, Michael Ekstrand <michael@elehack.net> wrote:
Jens,

On 03/10/2013 12:33 AM, Jens Petersen wrote:
> 1. build and install ghc-rpm-macros
> 2. build and install ghc with bootstrapping set in ghc.spec
> 3. build and install bootstrap (static) hscolour (I should probably just give up and make it statically linked)
> 4. rebuild ghc (with bootstrapping unset) and install it
> 5. rebuild dynamic hscolour (can also be done later as needed)
>
> Then you should be fine.  I hope I didn't miss anything.

Thanks! If I need to build ghc-rpm-macros twice (it doesn't seem to
build non-bootstrapped before the new ghc is built), where in the
process does the non-bootstrap build come? Or does it matter much?

>> 2. Is anything else needed? Or am I good to go rebuilding additional
>> Haskell packages in dependency order once I've bootstrapped
>> ghc-rpm-macros, ghc, and hscolour?
>
> You should be yes: but if not, if you can tell what went wrong
> I can try to be of more help.

The symptom I was seeing was segfaults, specifically in HsSyck.  Given
that I wasn't confident in my build, and had seen some anomalies while
working on it, I want to make sure that I have the stack properly built,
then try to chase down whatever might be wrong on the HsSyck side.

- Michael

_______________________________________________
haskell mailing list
haskell@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/haskell