ANNOUNCE: GHC 7.2.1 Release Candidate 1
marlowsd at gmail.com
Fri Aug 5 10:46:39 CEST 2011
On 05/08/2011 08:45, Jens Petersen wrote:
> On 5 August 2011 05:27, Ian Lynagh<igloo at earth.li> wrote:
>>> >from http://koji.fedoraproject.org/koji/getfile?taskID=3251249&name=build.log .
>> | *** unexpected failure for fed001(normal)
>> but it works fine for me on x86/Linux.
>>>> Note the Fedora build is patched to use system libffi.
>> Hmm. What happens if you don't patch it?
> More hmmm: that makes the x86 unexpected errors go to 0!
> I attach system libffi patch if anyone wants to look at it,
> but I don't see anything particularly arch-specific about it though so I still
> don't understand why it fails for 7.2. A similar patch for ghc-7.0.4
> doesn't seem to have any ill-effects on the test results:
> eg http://koji.fedoraproject.org/koji/buildinfo?buildID=248071
> I'd be interested to know if any other distros can reproduces or not.
> I think the system libffi patch originally comes from Debian.
This is surprising because I don't think ordinary FFI code should be
even using libffi on x86 - we have our own implementation in
rts/Adjustors.c. In 7.2 there are some changes in this area because we
now guarantee to keep the C stack pointer aligned on a 16-byte boundary
(see http://hackage.haskell.org/trac/ghc/ticket/5250), and as a result
we switched to using the Mac OS X implementation in rts/Adjustors.c
which was already doing the necessary alignment.
You aren't setting UseLibFFIForAdjustors=YES anywhere, are you? (even if
you were, I would expect it to still work though, albeit a bit more slowly).
> It would be good to make Linux default to use system libffi anyway.
> Is there any good reason not to do so? As you know copy libraries
> are frowned upon in the linux world. I can't remember if such
> an RFE already exists in trac?
I don't like having to do this, but it reduces our testing surface (we
don't want to have to test against N different versions of libffi). I'm
quite happy for distros to build against their system libffi though, and
we should make that easier. Note that if you build against the system
libffi you are responsible for fully testing the combination (I know you
already do that, which is great).
More information about the Glasgow-haskell-users