Building GNUstep with Clang, Blocks, and Grand Central Dispatch

From GNUstepWiki

* GCD is more than just a C library. It requires support from the kernel with light threads (libpthread), and an adptation of BSD signals for Linux (libkqueue).

* GCD is more than just a C library. It requires support from the kernel with light threads (libpthread), and an adptation of BSD signals for Linux (libkqueue).

* Blocks: Using blocks with GCD will often result in simpler and more elegant code, but blocks are not part of standard C. Mark provides a 'blocks' library called 'libblocksruntime', but even better, GNUstep has its own implementation of blocks. The two libarires are based on Apples blocks library and have the same API. However, what is not obvious is that the ABI of libblocksruntime is C, however the ABI of GNUstep is objective C. And mixing the two ABIs could lead to memory corruption under certain circumstances. ([https://github.com/nickhutchinson/libdispatch/issues/2 See xcvista's second comment].)

* Blocks: Using blocks with GCD will often result in simpler and more elegant code, but blocks are not part of standard C. Mark provides a 'blocks' library called 'libblocksruntime', but even better, GNUstep has its own implementation of blocks. The two libarires are based on Apples blocks library and have the same API. However, what is not obvious is that the ABI of libblocksruntime is C, however the ABI of GNUstep is objective C. And mixing the two ABIs could lead to memory corruption under certain circumstances. ([https://github.com/nickhutchinson/libdispatch/issues/2 See xcvista's second comment].)

-

In fact, I did try to get libdispatch on Kubuntu 13. I found that the gcc package must be installed in order to get the objc.h header to compile against, and I had to put the location of objc.h in <GNUstep root>/Makefiles/config.make, as well as adding clang in there. Being new to GNUstep I had a couple of other issues, and I started having the "bad smell" feeling that goes with graunching two ABIs. In addition, expert posts to the gnustep-discuss newsgroup this year consistently recommended installing from source, so to the the source we go.

+

In fact, I did try to get libdispatch working on Kubuntu 13. I found that the gcc package must be installed in order to get the objc.h header to compile against, and I had to put the location of objc.h in <GNUstep root>/Makefiles/config.make, as well as adding clang in there. Being new to GNUstep I had a couple of other issues, and I started having the "bad smell" feeling that goes with graunching two ABIs. In addition, expert posts to the gnustep-discuss newsgroup this year consistently recommended installing from source, so to the the source we go.

== libobjc2 and gnustep-base installation from source ==

== libobjc2 and gnustep-base installation from source ==

Revision as of 02:40, 3 June 2013

This guide shows how to install GNUstep-base with clang, blocks and Grand Central Dispatch on Linux.

Grand Central Dispatch is a library to assist building apps on multi-core processors. The library for Grand Central Dispatch is called libdispatch, and tasks can be submitted to GCD in blocks or with a C API. To understand the process below, some notes are in order. If you're in a hurry, you can probably skip the notes down to the install instructions.

GNUstep runtime

So far as GNUstep, the runtime library for Objective C code used to be called libobjc until Apple released Objective C version 2, and then is called libobjc2. You can get the background here: http://wiki.gnustep.org/index.php/ObjC2_FAQ . (Note Debian and Ubuntu libobjc3 and libobjc4 are still based on libobjc and libobjc2 but numbered differently).

libobjc2 built with GCC 4.6 and 4.7 has most of Objective C v2 supported, but doesn't have blocks support

libobjc2 built with Clang does have block support: (use -fblocks flag when compiling your own code)

GNUstep provides block support, whether the compiler does or not. So if using GNUstep, you can use blocks with a GCC libobjc2.

libdispatch currently has some build requirements that necessitate using clang.

So we're going with a clang build since a working GCD is the aim here.

Next, we observe that Debian wheezy and Ubuntu 13 have a libdispatch infrastructure built on clang (libobjc2 and libdispatch are built using clang). So there are some more decisions:-
Why not just run with what Debian provides instead of compiling from scratch, i.e.

libobjc2, libdispatch, cblocksruntime compiled with erlang

gnustep programs compiled with gcc

To make a decision, here is some background on GCD and blocks

GCD: As far as I can make out, there are two implementations of GCD out there for Linux. One by Mark Heily and one called libxdispatch. So far as using GCD with GNUstep, Mark's library is the one to use, and this is also the libdispatch library in Debian and Ubuntu.

GCD is more than just a C library. It requires support from the kernel with light threads (libpthread), and an adptation of BSD signals for Linux (libkqueue).

Blocks: Using blocks with GCD will often result in simpler and more elegant code, but blocks are not part of standard C. Mark provides a 'blocks' library called 'libblocksruntime', but even better, GNUstep has its own implementation of blocks. The two libarires are based on Apples blocks library and have the same API. However, what is not obvious is that the ABI of libblocksruntime is C, however the ABI of GNUstep is objective C. And mixing the two ABIs could lead to memory corruption under certain circumstances. (See xcvista's second comment.)

In fact, I did try to get libdispatch working on Kubuntu 13. I found that the gcc package must be installed in order to get the objc.h header to compile against, and I had to put the location of objc.h in <GNUstep root>/Makefiles/config.make, as well as adding clang in there. Being new to GNUstep I had a couple of other issues, and I started having the "bad smell" feeling that goes with graunching two ABIs. In addition, expert posts to the gnustep-discuss newsgroup this year consistently recommended installing from source, so to the the source we go.