Getting Objective-C 2.0 to work on Debian's GNUstep with clang

If you are a Cocoa or Cocoa Touch developer, you may have attempted to use features such as properties in GNUstep, only to be surprised that these don’t seem to be supported. This is because these are Objective-C 2.0 features.

To get the new features, the only way is to use a different compiler called clang. You may have seen this compiler used in newer releases of Xcode. This is a compiler that targets a virtual machine called LLVM before producing native code.

UPDATE May 4th 2011: GCC 4.6 has got the Objective-C 2.0 treatment, and since Debian includes GCC 4.6, I’d recommend you to try compiling your software that way. Not because it’s a better compiler — I have no idea which one works better — but because it’s there. Also, consider compiling GNUstep from trunk using GCC 4.6; it’s rather easy to do. (CC=gcc-4.6 ./configure, whenever compiling a component of GNUstep).

Let’s presume you managed to run an Objective-C program with GNUstep; that is, let’s presume you are aware of Project Center, or GNUmakefiles. If you are didn’t use GNUmakefiles, you should know that Project Center generates these in order to build your app.

Now you want to switch to clang, and you want to do so on your favorite operating system, Debian GNU/Linux.

Step 1:

apt-get install clang

Step 2:
Since some GNUstep files refer to , we need to have that file installed as well. Sadly it’s not installed as part of any runtime; it is, instead, installed as part of gobjc-x.x package. This may change by the time you use these instructions; see: for a list of packages that contain this file.
As of Dec 6th 2010, this is the package that needs to be installed:

apt-get install gobjc-4.3

You could also install gobjc-4.2, but let’s go with 4.3 for now.

Step 3:
We need to tell GNUstep to use the new compiler. We’ll need to edit one of template makefiles that GNUmakefile files use.

sudo $EDITOR /usr/share/GNUstep/Makefiles/config.make

Yes, that’s right: the easiest way I could find involves changing stuff in /usr (meaning upon package upgrade this might get overwritten — go figure).

Step 4:
Just below the license text, you should find the section “Binary and compile tools” which sets various variables such as CC, OBJCFLAGS, et cetera. Edit the relevant lines accordingly!

CC = clang
OBJCFLAGS = -I/usr/lib/gcc/i486-linux-gnu/4.3/include
CPP = clang -E

(Note the fugly path that we add to include path by setting OBJCFLAGS: We need to give clang the path to objc/objc.h; if one of them is different, edit the architecture name and gobjc version accordingly)

That’s it! @property, @synthesize and other friends you made while using Objective-C 2.0 under OS X are back in da hood, makin’ programming enjoyable once again. Plus, you get the extra build speed that clang provides, being somewhat faster than GCC.


15 thoughts on “Getting Objective-C 2.0 to work on Debian's GNUstep with clang

  1. John Doe


    I have GNUstep and clang installed on Debian 6, I can compile and run application in Project Center with gcc (default settings, no modification to config.make).
    I can also use clang from command line like this –
    clang rc.m -o rc -I /usr/lib/gcc/i486-linux-gnu/4.4/include -I /usr/include/GNUstep -L /usr/lib/GNUstep -lgnustep-base -fconstant-string-class=NSConstantString

    But changeing config.make as in your blog does not help at all.
    Compilation fails with
    81:11:fatal error: 'objc/objc.h' file not found


  2. John Doe

    Hi again,

    1. I hacked the rules.make file and added into ALL_OBCFLAGS
    -I /usr/lib/gcc/i486-linux-gnu/4.4/include as the very first option, everything else I left as was.
    2. And I am using your CC = clang etc as above in config.make.

    Thats it. But it is one ugly hack.

    rgds, JD

  3. Ivan Vučica Post author

    Personally, I think clang should be the default compiler for Objective-C on any platform where it's available 🙂

    I may yet file a bug report, but by its age, it seems that GNUstep on Debian is sort-of abandonware, so I'm not sure if it'll be acted upon.

    I'd personally want the maintainer to first update to the latest GNUstep; switch to clang would be secondary, although it would allow Objective-C 2.0 in the easiest way.

  4. John Doe


    To be honest, I did not get it up and running properly, importing Foundation.h results in /usr/include/GNUstep/Foundation/NSException.h:42:2: error: #error The current setting for
    native-objc-exceptions does not match that of gnustep-base … please correct this.
    I think it is time to buy a Mac.
    All this GNUstep seems to be a lot of crap. All I wanted was to try and learn ObjC 2.0 o Linux, but I have not figured out how to to it.

    Do you know a way how to get all those ObjC goodies up and running on Linux? I give up.

    As I said – if anybody is interested in ObjC 2.0, then one needs to buy a mac. Afterall, whats the point of using it on any other platform? Intresting language, though.

    rgds, JD

    1. Ivan Vučica Post author

      Point of using ObjC on other platforms is faster development on other platforms 🙂
      I like the way GUI development works under ObjC and Cocoa, and I don't want to be stuck just to Mac to work with it.

      While I haven't had the problem you did, you could always just use Objective-C 1.0 and what came with Debian. That's what I did while poking around, but in the end I just wanted to use @property, and other niceties of Objective-C 2.0. You don't have to do that. You could simply use Objective-C 1.0 features, and later learn how to use 2.0 features when you need them and when you are able to configure the environment to use them. They are NOT required for easy development — they simplify some things, but they're not needed!

      As for getting 2.0 to work under Linux, my above post outlines what I did. I took a pure installation of GNUstep on Debian, I installed clang, and I used a few tricks to get GNUstep to switch to clang. That's all I needed to do!

      Your alternative is forgetting about GNUstep from binaries, and simply compile it from scratch. I haven't done that (yet), but I saw that there are some fine tutorials out there on how to do this.

      GNUstep is not a piece of crap, and neither is Cocotron (for which you do need a Mac, though). They however both need to be handled with a lot of care.

      I wouldn't advise you to give up. Getting a Mac is never a bad choice if you can afford one, but I'm interested in GNUstep even on a Mac. Because in case I want to give up on Apple, I'll still have a way to develop software in my currently favorite language.

    2. Anton

      It works.
      In the morning I was stuck as you, but now I obliged it to work.
      Here is my GNUmakefile:

      include $(GNUSTEP_MAKEFILES)/common.make

      CC = clang
      APP_NAME = Properties
      Properties_OBJC_FILES = myclass.m main.m
      ADDITIONAL_CPPFLAGS += -I/usr/include/GNUstep -I/usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.5.2/include -I/usr/include/x86_64-linux-gnu

      include $(GNUSTEP_MAKEFILES)/application.make

      1. Ivan Vučica Post author

        You may also want to consider using GCC 4.6 if you only want to use Objective-C 2.0 features 🙂

        When I realized that GCC 4.6 is in Debian, and that I couldn't easily get newer GNUstep to compile with clang + gcc4.5 runtime, I took the easier route and switched to GCC 4.6. I'll update my post.

  5. Dimitris

    Hi, I was too curious to whether I could use GNUstep with clang. I am not very knowledgeable about how the language runtime and the framework are coupled together. Could it be that GNUstep is not coupled at all with the GCC Objective-C runtime implementation?


    1. Ivan Vučica Post author

      Both Clang and GCC can output code for the so-called GNU runtime, which ships everywhere with GCC.
      Both Clang and GCC can output code for the so-called Apple runtime, which ships only with OS X and iOS.

      There is an additional GNU runtime-compatible implementation called "GNUstep runtime" or libobjc2. To make things more confusing, this is not the libobjc2 package shipping with Debian.

      GNUstep can definitely run with the GNU runtime, and hence with the libobjc2. I don't think it was really designed to run with Apple runtime, since there is obviously no need for that (given that Cocoa ships with Apple's runtime).

      GNU runtime does not ship with Clang, to the best of my knowledge. But as long as you have GCC installed, you can get Clang to use headers and libraries from the GNU runtime that ships with GCC.

      Hope this clears some things up!

      1. Dimitris

        Well to be honest not much 🙂 So right now we have:

        1. The "GNUstep runtime" ( libobjc2 ) which I suppose is this:

        2. The "GCC runtime" ( libobjc ??? ) which is this:


        So on a vanilla Ubuntu 11.10 by installing GCC + GNUstep I will end up with option #2 ?

        But if then I also install Clang I will have both, and clang will compile with #1 and gcc with #2 ?


        PS. Isn't ironic the name *GNU*step runtime when it is MIT licensed living in the Clang repository?

        1. Ivan Vučica Post author

          Yes, you've identified the runtimes correctly. For more explanation about the runtimes, see this FAQ:

          Yes, installing GCC + GNUstep will give you option #2.

          No, installing Clang will not give you libobjc2. libobjc2 is installed completely separate from the compiler.

          Both GCC and Clang can work with both GCC runtime (also known as GNU runtime) and GNUstep runtime. Both GCC runtime from GCC 4.6 and GNUstep runtime provide Objective-C 2.0 features, but GNUstep runtime does some things a bit better. Clang could use pre-GCC 4.6 runtime with Objective-C 2.0, but could not provide all features – code could be compiled, but not everything could work.

          The story is already becoming too complex (not even mentioning fragile and non-fragile ABI). I am not familiar with intricacies of runtimes and compilers. However, GNUstep runtime and Clang seems to be the best combination, based on the traffic I see on the mailing list.

          libobjc2 does not live in Clang. If you take a look at the release notes, this was the URL mentioned: svn://

  6. Salil Wadnerkar

    if we use GNUmakefile, we don't have to modify the system files. I could successfully build my hello world program using the following GNUmakefile:

    include /usr/share/GNUstep/Makefiles/common.make

    CC = clang
    TOOL_NAME = hello
    hello_OBJC_FILES = hello.m
    hello_INCLUDE_DIRS = -I/usr/lib/gcc/i686-pc-linux-gnu/4.7.2/include/

    include /usr/share/GNUstep/Makefiles/tool.make

    1. Ivan Vučica Post author

      Sure, but that may not be what you want to do. It surely wasn't in my case.

      I wanted to build existing projects without having to modify their makefiles as you described. And modifying the system configuration is also a good idea if you don't want your own makefiles to be system dependent.

      Ideally, the system would be already correctly set up for building with whatever the compiler actually works on that system. And in fact it is — under Debian, that compiler is picked for you and it's GCC. So ideally you don't touch anything, and every source package's GNUmakefile listens to system's proscriptions on how to build itself.

      So the GNUmakefile should probably be system-agnostic and let the detected and configured GNUstep installation perform the build to the best of its ability. Modifying the GNUstep installation helps with configuring it to use Clang; modifying the GNUmakefile just makes it break on a system where clang isn't installed, or where the user upgraded from (in your case) GCC 4.7.2 (or where 4.7.2 was never installed).

      Thanks for dropping by!

    1. Schr3da

      You need to run the script twice -> you will get the first time an compiling error during installation


Leave a Reply

Your email address will not be published.


What is 7 + 2 ?
Please leave these two fields as-is:
IMPORTANT! To be able to proceed, you need to solve the following simple math (so we know that you are a human) :-)

This site uses Akismet to reduce spam. Learn how your comment data is processed.