Is libffi obsolete? Is it desirable and/or feasible to run it on OS X anymore? Looks like it isn't under active development. http://sourceware.org/libffi/ https://svn.macosforge.org/projects/macports/ticket/10232 Mark
On Sep 19, 2006, at 23:22, Mark Duling wrote:
Is libffi obsolete? Is it desirable and/or feasible to run it on OS X anymore? Looks like it isn't under active development.
The PyObjC project maintains their own, modern fork of libffi, which is what the port fetches. -landonf
gcc also provides its own and I see this port more like a potential source of troubles than anything else. yves Le 06-09-20 à 11:39, Landon Fuller a écrit :
On Sep 19, 2006, at 23:22, Mark Duling wrote:
Is libffi obsolete? Is it desirable and/or feasible to run it on OS X anymore? Looks like it isn't under active development.
The PyObjC project maintains their own, modern fork of libffi, which is what the port fetches.
-landonf _______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
On Sep 20, 2006, at 5:39 PM, Landon Fuller wrote:
On Sep 19, 2006, at 23:22, Mark Duling wrote:
Is libffi obsolete? Is it desirable and/or feasible to run it on OS X anymore? Looks like it isn't under active development.
The PyObjC project maintains their own, modern fork of libffi, which is what the port fetches.
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. The copy of libffi at the head of the PyObjC repository supports both darwin/ppc and darwin/x86 (it passes all libffi unittests on these two platforms). It is a partial copy of libffi, I have removed all files that are needed for support of other architectures to futher "document" that our copy of libffi is a limited fork. If someone wants to port our changes to the trunk of GCC I'm willing to answer questions. At one point I did try to do that port, but as their copy of libffi doesn't compile with the version of gcc that is shipping with Xcode 2.3 I gave up before actually starting. Ronald
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. Mark
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 ;-) Ronald
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. yves
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.
Le 21 sept. 06 à 21:27, Ronald Oussoren a écrit :
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.
Done. I have a multiplatform project based on PyObjC's libffi (for the OSX/ x86 & ppc builds) and it works just fine, so I don't understand what all this discussion is about. Paul -- Ministre ultraplénipotentiaire en disponibilité. Mobile. Sans baignoire fixe. http://www.kallisys.com/ http://www-poleia.lip6.fr/~guyot/
Paul Guyot <pguyot@kallisys.net> writes:
I have a multiplatform project based on PyObjC's libffi (for the OSX/ x86 & ppc builds) and it works just fine, so I don't understand what all this discussion is about.
The discussion is over my head, but thanks for updating the port. I've asked the bug reporter of 10232 to try it and hopefully that bug can be closed soon. Thanks again. Mark
participants (5)
-
Landon Fuller
-
Mark Duling
-
Paul Guyot
-
Ronald Oussoren
-
Yves de Champlain