Re: GNUstep base almost builds with clang

[David Chisnall]

On 31 Mar 2009, at 20:00, David Ayers wrote:

> I'm mostly concerned about keeping support for deprecated API which  
> was
> 1) part of either the OpenStep specification.
> 2) part of OPENSTEP 4.2 (widely distributed cross platform
> implementation of OpenStep)
> 3) part of WebObject 4.5 (last cross platform implementation of
> OpenStep)

I'd agree with this.  -forwardForProxy:selector:argFrame: is not part  
of OpenStep.  I don't know if it was part of OPENSTEP 4.2 or WO - my  
impression was that it was a private GNUstep method that had since  
been superseded by the ffi stuff.

> If we can implement the argframe approach (ie. -forward::) via libffi
> then we could also resolve some long standing libobjc issues.  Yet I'm
> still unsure if it can be done at all.
>
> I'm also a bit concerned about statements like "I believe ...[some
> code]... never worked correctly" as we simply do not know who is using
> it and whether it works for production code.  Mostly one finds out  
> that
> things stopped working when it's too late...

Reading the GCC and GNUstep lists, __builtin_apply() and friends are  
in the 'it may work, but if it stops working randomly then don't be  
surprised' category.  Every time someone asks a question about them on  
the GCC lists, the reply seems to be 'don't use them unless you  
absolutely have to'.

I am only proposing that we deprecate bits of GNUstep that are not in  
code paths that are used in the standard configurations and have not  
been for several years, including some parts that contain comments  
indicating that they probably don't work.

> (For example currently it
> seems that gcc 4.5 may be breaking obj-c++ in gcc because Apple isn't
> maintaining it anymore, and I hardly know anything about c++ to be of
> much use here... I'm am trying to takle some of the objc/libobjc  
> bits.)

This is one of the reasons I want to get clang supporting GNUstep.  C+ 
+ support in clang is still very immature, but it is improving at a  
rapid pace, and Apple has several people working on it full time.   
Because it uses a unified parser, the Objective-C++ front end supports  
everything that C++ one does. All we need to do to be able to make use  
of this is ensure that the CGObjCGNU class is implemented correctly.

> What I'd /really/ like to see is that we would start setting up our
> "Test Farm" to also run the test suite and possibly get something  
> like:
> http://gcc.gnu.org/wiki/CompileFarm
> running for "Supported Platforms".  But even if we had access to  
> such a
> farm, I don't really have the time to volunteer to maintain it.
>
> > NSInvocation.m uses them in the fall-back code for when ffcall and
> > libffi are not present.
>
> I think we should deprecate the fallback and log a message asking  
> users
> who stumble over it to post their architecture/platform information.
> The goal would be to find someone who could implement libffi support  
> for
> that architecture/platform.

I'd suggest modifying the configure script.  The ffcall implementation  
doesn't work safely with EtoileThread, since it does not provide a  
mechanism for preventing the invocation from trampling over a random  
stack address if it lasts longer than the call frame.  When I reported  
this, there was talk of deprecating ffcall, since there don't appear  
to be any platforms where GNUstep and ffcall work but libffi doesn't.   
I would suggest that for the next release we require libffi and see if  
anyone complains.

> > NSObjCRuntime.m uses mframe_next_arg in NSGetSizeAndAlignment().
> >
> > The stuff for decoding type strings should probably be pulled into a
> > separate file.
>
> Indeed... I think I once started a patch to extract mframe_next_arg  
> into
> GSObjCRuntime.m under a different name.  I'm not sure anymore what
> happened to it.  But I agree that this function shouldn't need any of
> the code in mframe.m itself.
>
> > > > 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.
> >
> > This function seems to be part of an attempt to reproduce the old  
> > NeXT
> > runtime API.  More recently, I've been working on implementing the
> > ObjC 2.0 runtime API (supported by Apple for both their new and old
> > runtimes) on top of the GNU one.  You can see the current version  
> > here:
> >
> > http://svn.gna.org/viewcvs/etoile/trunk/Etoile/Languages/RuntimeAbstraction/
> >
> > At some point, I'd like to push this up to GNUstep[1] and have the
> > Apple runtime APIs properly supported.  Now that Apple has deprecated
> > posing and defined a stable public API for the runtime, I would
> > imagine a lot of programs are going to start using it.
>
> I think the proper place to put this is FSF libobjc.  I'd support a
> request to dual-license the respective files.  (Not that I have any  
> real
> clout but if we as a project request it, maybe are chances are not  
> that
> bad.)

Has anyone heard anything from the FSF about relicensing the GNU  
runtime?  It is currently GPL with an exemption that only applies if  
code is compiled with GCC.  I was told about a year ago that it would  
be moved to the same exemption as libc (which allows linking of any  
code), but haven't heard anything since then.  I'm not really  
interested in working on adding Objective-C 2 support to the GNU  
runtime until this change has taken place.

David