Re: Trying to use GNUstep and libdispatch in an ARC based objective-C program

[Quentin Mathé]

Hi David,

Le 8 janv. 2014 à 13:17, David Chisnall a écrit :

> Hi Quentin,
> 
> On 8 Jan 2014, at 09:32, Quentin Mathé <qmathe@gmail.com> 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.