Re: GNUstep base almost builds with clang

[Richard Frith-Macdonald]

On 30 Mar 2009, at 16:37, David Chisnall wrote:

> The remaining issue is that clang (and llvm-gcc, for that matter)  
> does not support the __builtin_apply() family of intrinsics.  These  
> are quite unreliable on GCC, and it seems that they are not used  
> when FFCall or FFI is supported, but are still compiled in.
>
> mframe.m (which is really horrible) seems to be compiled  
> unconditionally, even though it does not seem to be used when ffcall  
> or libffi is provided.
>
> NSInvocation.m provides default implementations in terms of  
> __builtin_apply() and friends that are not used when libffi or  
> ffcall is provided.  Is it possible to move these into a separate  
> concrete subclass of NSInvocation along the lines of GSFFIInvocation/ 
> GSFFCallInvocation and only compile them when no better mechanism is  
> provided?

I should think that's not only possible, but a very good idea.

I *think* (iirc) a little of the code in mframe is used for some  
NSMethodSgnature features.  It may be that we always need that part  
compiled in, but it should be possible to separate out what we need,  
and only build the rest of the code if we don't have libffi or ffcall.

> objc-gnu2next.m uses them in a function that is deprecated on the  
> legacy Apple runtime and not supported by the modern Apple runtime.   
> Does anyone actually use next_objc_msg_sendv()?

I don't but it's always dangerous to assume that nobody else will.  On  
the other hand, that's old enough that we might insist on people  
changing.  The next major release will need to break ABI compatibility  
for 64bit code in order to be compatible with Apple's recent changes,  
so now is probably a good time to introduce other cleanups that break  
the ABI in little-used or unused ways.