gnustep-dev
[Top][All Lists]
Advanced
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GNUstep base almost builds with clang

From: David Chisnall
Subject: Re: GNUstep base almost builds with clang
Date: Wed, 1 Apr 2009 00:48:14 +0100 
On 1 Apr 2009, at 00:28, David Ayers wrote:


Am Dienstag, den 31.03.2009, 22:13 +0100 schrieb David Chisnall:

On 31 Mar 2009, at 20:00, David Ayers wrote:
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.


OK, but the consequence is deprecating platforms.  And that should be
stated and communicated as such. I'm not too fond of doing that without 
very good reasons.
Are we? What platforms currently have no support for either ffcall or libffi, but do have support for __builtin_apply()? (Note the last condition; the further you get from Linux/x86, the less likely __builtin_apply() is to actually 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.
Well I'm not too fond of yet another compiler/runtime to support... but 
if it is what apple will be using and it will also replace the current
apple runtime, I'm glad someone is working on it. But I think will need insure that our current main compiler / runtime stays in (or is restored 
to) a decent condition.
Neither am I, but no one on the GCC side seems to be working on Objective-C. I tried to persuade the FreeBSD port maintainer to enable ObjC++ recently in the default build, and his reaction was that ObjC was basically unmaintained in GCC and ObjC++ was in an even worse state.
Someone at Apple created some patches over a year ago for adding support for properties to GCC on the GNU runtime. Are they merged yet? No. Is anyone planning on merging them, or rewriting their functionality? Not as far as I can see. Do any of the GCC folks outside of Apple give a dam about Objective-C? Not that I can tell; we had a /stable/ release ship generating errors with any Objective-C program containing constant strings a while ago, and the GCC response was 'Objective-C is not a priority'.
If we continue to treat GCC as our main compiler then run the risk that we are depending on a project which has no interest in maintaining the features we need. As far as I can tell, the only reason ObjC is even included in the default builds for GCC is so that the FSF can keep that page telling everyone how great the GPL is because it got GCC its ObjC front-end and ignoring the fact that the code they got was horrible, unmaintainable, and completely useless until someone wrote a libobjc implementation (which ended up being more code than the compiler front end).
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.


Where do you get the information that "there don't appear to be any
platforms where GNUstep and ffcall work but libffi doesn't"?  IIRC
peoples mileage varies.  But indeed we need to start documenting which
works with which.
From the mailing list when I asked this last, and from comparing the list of supported platforms for the two. Again, can you name one platform supported by ffcall and GNUstep, but not libffi? Does anyone want to jump in and say 'My platform doesn't support libffi! Please don't drop support!' or is this all hypothetical? 


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.
Just to be clear, I highly doubt (and I wouldn't support) a re- licensing 
of the GNU runtime as a whole.  I was merely suggesting dual-licensing
the files which you'd like contribute yet retain under an MIT license.
Currently, the GPL exemption for GNU libobjc only applies to code compiled with GCC. If we compile GNUstep with any other compiler, then this exemption does not hold. Since new versions of the runtime are GPLv3, this means we can't, for example, link PopplerKit (GPLv2- only) with it, and we can't link (for example) LuceneKit (Apache license) against the older GPLv2 version.
GNU libc has a different exemption, which does not specify the compiler. I was told a year ago that GNU libobjc would move to using the same exemption, once the phrasing was worked out for the GPLv3. This will allow libobjc to be used in exactly the same way GNU libc is currently used.
If this change isn't going to happen, then there is not much point working to support the GNU runtime with clang and, since there is little chance of GCC ever adding new features to Objective-C, there is no point in my adding new features (properties, non-fragile ivars) to GNU libobjc. 

David
reply via email to
[Prev in Thread] Current Thread [Next in Thread]