[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: GNUstep base diff to compile with clang
From: |
Richard Frith-Macdonald |
Subject: |
Re: GNUstep base diff to compile with clang |
Date: |
Mon, 17 Aug 2009 08:27:36 +0100 |
On 15 Aug 2009, at 17:00, David Chisnall wrote:
Hi Everyone,
I've attached a diff that lets GNUstep-base compile with clang[1].
With this applied, I built GNUstep base with clang by doing:
$ ./configure --with-ffi-include=/usr/local/include --with-ffi-
library=/usr/local/lib --enable-libffi CC=clang
$ gmake CC=clang LD=gcc
I needed to hack the output of configure slightly, because it
defaults to NXConstantString as the constant string class when the
compiler doesn't let you set one, while clang (like Apple's GCC)
uses NSConstantString as the default. This test should really use
whatever [[@"foo" class] className] returns as the correct class.
GNUstep currently doesn't handle the case where the constant string
class is different in two libraries. I can't think of a simple
solution to this, so I'll probably add the constant string class
option to clang.
This patch does the following:
- Removes various mframe things from being compiled when ffcall/
libffi is used (mframe.m, NSConnection.m, NSInvocation.m)
- Removes objc-gnu2next.m from being built (it's ugly and broken
code, and can be implemented better as a trivial macro)
- Tweaked NSObject to use atomic ops with LLVM as well as gcc (this
probably isn't actually needed)
- Added a SIGFPE handler on FreeBSD. No idea why, but without this
calling floor() on FreeBSD crashes (but, strangely, with it calling
floor() doesn't call the handler. Weird, no?).
- Turned a nested function in make_strings into a macro. Nested
functions are bad, m'kay? (They require an executable stack, and
won't work even with GCC on any OS which doesn't allow this, e.g.
OpenBSD).
With this patch applied, I can compile GNUstep base with clang and
run simple programs. GUI programs are currently crashing for me,
but I'm not sure why.
David
[1] Currently, this requires a slightly patched clang, but the diffs
required should be committed this week.
Great changes ... thanks very much.