This is the mail archive of the
libffi-discuss@sourceware.org
mailing list for the libffi project.
Re: Libffi merge [Was Re: [patch] powerpc libffi Net/FreeBSD ]
- From: Jack Howarth <howarth at bromo dot med dot uc dot edu>
- To: Andrew Haley <aph at redhat dot com>
- Cc: gcc-patches at gcc dot gnu dot org, libffi-discuss at sourceware dot org, java-patches at gcc dot gnu dot org
- Date: Thu, 4 Jun 2009 15:33:04 -0400
- Subject: Re: Libffi merge [Was Re: [patch] powerpc libffi Net/FreeBSD ]
- References: <4A256DDD.7060409@fgznet.ch> <4A25C34C.6020403@gmail.com> <4A2644EC.4030901@redhat.com>
On Wed, Jun 03, 2009 at 10:39:56AM +0100, Andrew Haley wrote:
>
> My first wodge of changes will be only the substantive differences
> in the library itself: later I'll get to the testsuite and the rest.
> To begin with, I'm just going to update upstream libffi with the gcc
> changes, and then see how much difference there is. I'm guessing not
> much.
>
> Questions for Anthony Green:
>
> 1. I don't understand the libffi version numbers. Can you give
> me any explanations? It seems to be 3.0.8 upstream but 2.1 in gcc,
> but this doesn't seem in any way to correspond with reality.
>
> 2. What's with the ChangeLog.libffi and ChangeLog.libgcj files?
>
> Thanks,
> Andrew.
Andrew,
Has there been any code exchange between the upstream libffi and
the forked libffi that PyObjC uses? I was told the following by Bill Bumgarner
at Apple a couple years back....
>> So... long story short.
>>
>> About 10 years ago, PyObjC forked libffi for use in the PyObjC
>> project. I don't remember exactly why it was forked, but forked it was.
>>
>> The PyOBjC version of libffi has been maintained over the years,
>> specifically targeted to Mac OS X. In the past year, it got quite a
>> bit of attention both to support the 64 bit variants of Mac OS X and
>> quite a bit of cleanup work (new testing infrastructure, man pages,
>> etc.etc.etc). It also grew an Xcode project.
>>
>> I would be perfectly happy to see all the changes folded back into the
>> FSF/GCC community version (as long as the license remains liberal --
>> but we can fork it at the point of change, if it ever changes) and no
>> longer have a forked version for PyObjC.
>>
>> But none of us have the time to fold together the decade+ of forked
>> development. At this point, the most likely path forward is to drop
>> the PyObjC version of FFI back into the PyObjC repository. It will,
>> at least, be widely accessible again.
>>
>> b.bum
...regarding the origin of the files at...
http://www.opensource.apple.com/darwinsource/10.5/libffi-10/
Jack