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 _______________________________________________ Discuss-gnustep mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnustep
