Hi Stephen,
Thanks for taking the time to do this! A few comments:
In the libobjc2 section... the runtime should support the same features
irrespective of what compiler it's built with, but you can't use blocks unless
you use clang.
GNUstep-base should be built with clang if you intend on using it with blocks
(we've made an effort to ensure that this isn't required, but it may not quite
work, and in particular the subclassing of NSRegularExpression won't work
correctly if GNUstep is not built with blocks support).
You shouldn't need the cblocksruntime packages. It now uses weak symbols, so
all of the functions that it would be providing are replaced by the ones in
libobjc2. You can skip the whole thing by just linking libobjc and not
libBlocksRuntime.
The objc.h header should be provided by libobjc2. If you're installing on
Linux and don't have GNUstep installed, then you may have problems because the
default install location for the headers will be in /usr/local/include/objc,
which won't be in your search path. Changing the prefix to /usr/ (from
/usr/local) should fix this.
In PC-BSD, chroots and jails are not the same things. If something has an IP
address, it's a jail and not a chroot.
What were the issues with libdispatch on PC-BSD? I use libobjc2 built from
source with libdispatch from ports and everything (including ARC integration)
works for me...
If you're using blocks, you're almost certainly using a version of clang that
supports the @autoreleasepool{} syntax, so you might consider using that for
your program. You might also consider using ARC, although for this example it
doesn't make a difference.
libpthread isn't light threads, it's the POSIX threading library. There are
some non-standard extensions for allowing the kernel to manage work queues
based on system load, but (unless you apply Stacy Son's patches to FreeBSD) on
non-Apple platforms they're just emulated in userspace.
libkqueue doesn't adapt BSD signals, it emulates the kqueue() interface for
receiving notifications of file descriptor events on top of Linux's epoll().
The GNUstep implementation of the blocks runtime is not based on the Apple
implementation, it was released six months earlier based on reading the code
Apple released in the compiler.
xcvista's comments that you link to are wrong. GNUstep implements exactly the
same ABI for blocks as Apple / LLVM's libBlocksRuntime, it just implements the
integration between blocks and the Objective-C runtime differently. It is
completely safe to compile and link libdispatch against LLVM's libBlocksRuntime
and then link your code against libobjc2. The weak symbols in libBlocksRuntime
will be ignored in preference to the ones in libobjc2.
On FreeBSD / PC-BSD, you can just install the libdispatch port and add
-ldispatch to your linker flags. This version works out of the box with
GNUstep (and doesn't have any GNUstep-specific patches applied, so others from
the same upstream should as well).
David
On 3 Jun 2013, at 22:53, Stephen Woolerton <sdw@shineonline.co.nz> wrote:
Hi everyone,
Just to let you know that I've added a howto for "Building GNUstep with clang,
blocks, and Grand Central Dispatch" to the GNUstep wiki.
It is at http://wiki.gnustep.org/index.php/User_Guides