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. I do remember that with respect to method signatures we rely on what gcc encodes. So we may simply need gcc support to ensure that methods that are implemented yet not declared are encoded. But IIRC that's just the tip of the iceberg. When Apple merged its 'ObjC improvements' into gcc they "simplified" the previously platform specific method signature encodings and now we are missing or using misleading information for some ABI's. This just emphasizes the fact that GNUstep should not really depend on either libffi nor ffcall for message forwarding or signature en/decoding, but that this should be encapsulated in libobjc. And gcc's test suite should include appropriate tests for all platforms we care about. I once started writing signature encoding tests, but it's a non-trivial task to write portable tests when the current signature generation is broken, and it fell off my radar. But in principal I think the correct direction is to - implement forwarding in libobjc - write gcc/libobjc tests for the platforms we care about - run (automated) gcc/libobjc regression tests for the platforms we care about - use libobjc for message forwarding in GNUstep The only issue I see here is that I don't know whether Apple's libobjc implements a forwarding API for Darwin based distributions which may be using Apple's runtime. OTOH, I don't know how useful Apple's current runtime is without Apple's Foundation as IIRC the runtime delegates much of it's work to (Core?)Foundation, but I haven't really investigated it deeply, not owning a Mac. Cheers, David _______________________________________________ Discuss-gnustep mailing list [email protected] http://lists.gnu.org/mailman/listinfo/discuss-gnustep
