Le 07-03-18 à 05:57, David Ayers a écrit :
Andrew Pinski schrieb:
On 3/17/07, Wolfgang Lux <[EMAIL PROTECTED]> wrote:
I do not see how this could ever be fixed, so I'm
inclined to think that GNUstep should drop libffi.
You know I have not see any bug reports from you about libffi. In
fact I rather have GNUStep always use libffi because it is more
supported with more targets (and the semi official base code is
inside
GCC). I am about to review the patch which used libffi instead of
__builtin_apply (etc.) inside libobjc also.
I tend to agree with Andrew. I have tried to contact ffcall
maintainers
for issues in either SPARC or NetBSD architectures and haven't had
productive responses.
IIRC, building the development environment for ffcall entails
non-portable configure scripts and specific gcc versions (2.7.?).
The problem is that both libffi and ffcall solve non-trivial problems
and /I/ haven't been able to easily find the documentation needed to
use/fix them... which makes formulating useful bug reports also
non-trivial.
But realize that libffi is what gcc's java implementation uses so for
the common platforms I believe the issues don't necessarily lay within
libffi.
BTW, it seems the only way to build libffi with gcc is to build java
(just objc won't do).
I can't really follow the discussion, but my need to oversimplify
things leads me to the following conclusions :
1- ffcall works better than ffi today
2- ffi has a brighter tomorrow
3- libobjc would be better by its own (after tomorrow)
not too far off ?
thanks
yves
_______________________________________________
Discuss-gnustep mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/discuss-gnustep
