[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).
David
-- Sent from my Difference Engine
- Re: ANN: One Step to GNUstep - pre-release version 0.9, (continued)
- Re: ANN: One Step to GNUstep - pre-release version 0.9, Lars Sonchocky-Helldorf, 2011/06/14
- Re: ANN: One Step to GNUstep - pre-release version 0.9, Gregory Casamento, 2011/06/14
- Re: ANN: One Step to GNUstep - pre-release version 0.9, Ivan Vučica, 2011/06/13
- Re: ANN: One Step to GNUstep - pre-release version 0.9, Riccardo Mottola, 2011/06/13
- Re: ANN: One Step to GNUstep - pre-release version 0.9, Gregory Casamento, 2011/06/13
- Re: ANN: One Step to GNUstep - pre-release version 0.9, Richard Stonehouse, 2011/06/13
- Re: ANN: One Step to GNUstep - pre-release version 0.9,
David Chisnall <=
- Re: ANN: One Step to GNUstep - pre-release version 0.9, Riccardo Mottola, 2011/06/13
- Re: ANN: One Step to GNUstep - pre-release version 0.9, Ivan Vučica, 2011/06/13
- Re: ANN: One Step to GNUstep - pre-release version 0.9, Riccardo Mottola, 2011/06/13
- Re: ANN: One Step to GNUstep - pre-release version 0.9, Gregory Casamento, 2011/06/13