On Thursday, September 21, 2006, at 01:28PM, Yves de Champlain <yves@macports.org> wrote:
Le 06-09-21 à 04:15, Ronald Oussoren a écrit :
On Thursday, September 21, 2006, at 09:45AM, Mark Duling <mark.duling@biola.edu> wrote:
The file the port tries to download isn't the maintained copy of libffi. I've fully integrated the libffi build into the PyObjC build and we no longer distribute a current standalone copy of libffi.
gcc also provides its own and I see this port more like a potential source of troubles than anything else.
So am I hearing "this port is broke and will never work and should be deleted"? Or is it more a "wait and see and let it hang around for awhile more" type of thing. I hate to have ports in the tree that will never work because it causes confusion and bugs to be filed.
A port that works from the copy of libffi that is distributed by the PyObjC project is less than optimal. That version does not, and will never, support darwin/x86. That's nothing that can't be fixed through patches of course ;-)
All I know about ppc/x86 is that gnustep use ffi on ppc and ffcall on x86. I think gcc does not install ffi on x86.
AFAIK the libffi in GCC's tree does not yet support darwin/x86, it does support linux/x86 (and loads of other platforms). The problem here is that Apple has choosen to use an x86 ABI that is slightly different from the default SYSV ABI on x86, probably because they can generate better code with the darwin/x86 ABI. The version of libffi that is shipped in recent pyobjc releases and the pyobjc repository does support darwin/x86, but has a build procedure that is fully integrated with the pyobjc one. Someone that knows how to program C could IMHO easily extract darwin/x86 support from the PyObjC tree and create a standalone version of libffi that supports both darwin/ppc and darwin/x86. Ronald P.S. The last time I looked at GCC's copy of libffi is several months ago, things may have changed since then.