Hi David, Le 8 janv. 2014 à 13:17, David Chisnall a écrit :
> Hi Quentin, > > On 8 Jan 2014, at 09:32, Quentin Mathé <[email protected]> wrote: > >> It seems libdispatch ObjC integration is not compatible with libobjc2 as it >> is. When compiling code that uses libdispatch, I pass >> -DOS_OBJECT_USE_OBJC=0 to the CPPFLAGS, in order to disable the libdispatch >> ObjC integration. >> >> See >> http://stackoverflow.com/questions/8618632/does-arc-support-dispatch-queues > > It would be nice for us to support that. As I understand it, the only thing > missing is treating the libdispatch types as ARC-compatible types? I think so, but I haven't looked at it beyond the header that declare OS_OBJECT_USE_OBJC. >> Based on my experience, this repository requires various changes to compile >> and work correctly on GNUstep. Some GNUstep people have submitted changes >> but they haven't been accepted yet. >> >> I maintain a fork of this repository patched with GNUstep+libobjc2 support >> here: http://svn.gna.org/viewcvs/etoile/trunk/Dependencies/libdispatch-objc2/ > > This patch shouldn't be needed. I use libdispatch on FreeBSD, and it links > against libBlockRuntime but then these symbols are weak so they're just > replaced if you also link to libobjc. There's absolutely no reason to use > the libobjc2 headers instead of the BlocksRuntime headers, even if you're > linking to libobjc instead of libBlocksRuntime. Unless I'm looking at the wrong repository, it doesn't seem the official libBlockRuntime have been updated to declare these symbols as weak: http://llvm.org/svn/llvm-project/compiler-rt/trunk/BlocksRuntime/ It's possible that recent FreeBSD and Ubuntu versions provide a patched version of libBlockRuntime where the symbols are weak. libblockruntime-dev packages on Ubuntu 12.04 (the version I use) doesn't seem to have weak symbols though. If I install this libblockruntime-dev package from Ubuntu, libdispatch compiles but doesn't use the libobjc2 block implementation and this causes crashes iirc. >> The changes I did are listed in this patch: >> http://svn.gna.org/viewcvs/etoile?view=revision&revision=9796 >> The main change is rewriting FindCBlocks.cmake to pick either >> libBlocksRuntime or libobjc2, depending on what is available on the host >> system. >> >> For the install instructions, see: >> http://svn.gna.org/viewcvs/*checkout*/etoile/trunk/Dependencies/libdispatch-objc2/INSTALL >> >> Another major problem that remains unsovled lies the fact that GNUstep Base >> doesn't attempt to detect libdispatch, and compile NSOperation and >> NSOperationQueue with libdispatch support enabled. As a result, you have to >> stick to the libdispatch C API. > > -base actually does detect libdispatch and uses it for a few things (e.g. > parallel iteration with NSArray), but it doesn't use it for NSRunLoop or > NSOperationQueue - both of these would be nice to add. ok, I didn't know about this. Cheers, Quentin. _______________________________________________ Discuss-gnustep mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnustep
