[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ANN: One Step to GNUstep - pre-release version 0.9

From: David Chisnall
Subject: Re: ANN: One Step to GNUstep - pre-release version 0.9
Date: Mon, 13 Jun 2011 16:31:02 +0100

On 13 Jun 2011, at 16:09, Richard Stonehouse wrote:

> Thanks, that's good to know. I see that openSUSE (the distribution I
> use) intends to adopt GCC 4.6 as default compiler in the next release
> but, currently, it is breaking quite a few of their package builds.
> However I don't know whether that is the fault of the compiler or the
> packages. I've seen no complaints about clang, but suspect this is
> because there is less work being done with it.

The only issues I've seen recently with clang have been caused by the 
integration of core libraries and headers with GCC packages, so the compiler 
hard-codes paths.  On some Linux distributions, standard headers are installed 
in non-standard locations with paths that change for every GCC release.  Clang 
needs to copy these hard-coded paths, which takes a little bit of effort and 
requires someone using the distribution to notice.  There are a few SuSE 
developers who are quite active in the LLVM community though, so hopefully this 
won't be a problem for you.

> Are you saying these are provided by clang but not by GCC 4.6?

Mostly.  A few are purely runtime features and don't require any compiler 
support.  These are available with GCC 4.6 and the GNUstep runtime.  Most 
require at least some assistance from the compiler.

> OK, from what you and Ivan say it seems clear that there's a need to do
> something about Objective C 2.0. I'll pull down the openSUSE packages
> of clang and gcc-4.6, and have a go at doing some GNUstep builds, then
> think about where to go from there. Either way, presumably, the GNUstep
> libobjc2 will be required.

It's not required for the core Objective-C 2 features, but it is required for 
the non-fragile ABI and most of the things on my earlier list.

> The licensing issues are important - we want to avoid lock-in. But
> this does not preclude developers using clang if it provides a better
> development environment. Dual-sourcing is good, if it is practicable.
> My worry is that the features supported by the two compilers may
> diverge (or have they done so already)?

The clang license is BSD-style.  It is a FSF-approved Free Software license.

GCC 4.6 supports a subset of the features of clang.  The biggest 
developer-visible example of this is the lack of blocks support.  Apple's most 
recent APIs make heavy use of blocks, so this is problematic for people coming 
from OS X.  GNUstep uses some macros to try to hack around this, but it's 
problematic in a few places.  For example the API documentation for 
NSRegularExpression requires that the primitive method be implemented with 
blocks and the other methods call this.  If you compile GNUstep-base with GCC 
then you get a version that doesn't work like that (because, while it's trivial 
to call blocks with macros, it's nontrivial to create them).

> What I'm leaning towards, if it turns out to be practicable, is using
> GCC 4.6 for the GNUstep library builds but including clang for
> developers' use. That is assuming there's no incompatibility between
> GCC-compiled GNUstep libraries and clang-compiled applications. But
> that's not necessarily my last word!

This would mean that you wouldn't be able to use blocks in -base, and you 
wouldn't be able to use the non-fragile ABI.  The main advantage of the 
non-fragile ABI is that you can add ivars to classes without needing to 
recompile their subclasses.  This is what the non-fragile part means: changes 
to one framework are much less likely to 

Unlike Apple's non-fragile ABI, the non-fragile ABI supported by the GNUstep 
runtime (and clang / LanguageKit) does permit code compiled with the GCC ABI to 
be used as well, but they suffer from the same limitations that they do in all 
contexts.  For example, if an application uses the fragile ABI, then it will 
need to be recompiled if framework classes that it uses are recompiled, even if 
they are compiled using the non-fragile ABI.  I'd have liked to do a 
break-the-world release, but the feedback I got suggested that this would lead 
to crowds of packagers with pitchforks and flaming torches outside my house.  

Clang uses a hybrid ABI when compiling in fragile mode, where it exports some 
extra metadata that only the GNUstep runtime will notice (the GCC runtime will 
ignore it).  


-- Sent from my Difference Engine

reply via email to

[Prev in Thread] Current Thread [Next in Thread]