Hi David,
Thanks for your "few comments". Great critique, I was hoping someone
would put their hand up to provide corrections like you have.
So far as I'm aware I've incorporated everything you said, and you may
like to check my post again to make sure I've captured your intent
accurately.
http://artinamessage.wordpress.com/2013/06/03/gnustep-install-with-clang-blocks-and-grand-central-dispatch-gcd/
And re libdispatch on PCBSD, the behaviour I observed was the same as on
Kubuntu. I've updated the section regarding PCBSD.
Cheers
Stephen
On 5/06/13 9:33 PM, David Chisnall wrote:
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 <[email protected]> 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
_______________________________________________
Discuss-gnustep mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnustep
