[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: libdispatch types in a property declaration

From: David Chisnall
Subject: Re: libdispatch types in a property declaration
Date: Thu, 23 May 2019 16:15:49 +0100
User-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1


I'd not looked at the Swift corelibs version of libdispatch. Looking at its headers, there are some feature test macros that check if you have Objective-C support, which seem to only enable Objective-C interop on Apple platforms:


You could add some checks to there to enable them on non-Mac platforms and see what happens when you build them...


On 23/05/2019 15:13, Simon Gornall wrote:
[I posted this in gnu.gnustep.discuss, but then realised that the last post before mine was back in January. Posting here where there’s more traffic :)]

Hi all,

So I've just installed Debian (Sid) and got GNUstep installed with runtime 2.0 / clang-8 etc. by following http://wiki.gnustep.org/index.php/Building_GNUstep_under_Debian_FreeBSD#libdispatch <http://wiki.gnustep.org/index.php/Building_GNUstep_under_Debian_FreeBSD#libdispatch>

As far as I can tell, it all worked fine. I got a few tests fail where the above link didn't mention, but they seemed to be to do with Objc++, and I'm not planning on using that. I put that down to running sid.

I have a project that compiles on my Mac, and I'm trying to port it over - part of it is a web-socket service, which uses libdispatch and blocks to process the data streams. On the Mac, there aren't any warnings. On the linux box, I get:

nano:~/src/b-leet.com/bleetd <http://b-leet.com/bleetd>> make messages=yes
This is gnustep-make 2.7.0. Type 'make print-gnustep-make-help' for help.
Running in gnustep-make version 2 strict mode.
Making all for tool bleetd...
/usr/bin/clang-8 bleetd/classes/server/Server.m -c \
      -MMD -MP -Ibleetd/classes/server -Ibleetd/classes/websockets -DGNUSTEP -DGNUSTEP_BASE_LIBRARY=1 -DGNU_GUI_LIBRARY=1 -DGNUSTEP_RUNTIME=1 -D_NONFRAGILE_ABI=1 -DGNUSTEP_BASE_LIBRARY=1 -fno-strict-aliasing -fexceptions -fobjc-exceptions -D_NATIVE_OBJC_EXCEPTIONS -pthread -fPIC -Wall -DGSWARN -DGSDIAGNOSE -Wno-import -g -O2 -fblocks -fobjc-runtime=gnustep-2.0 -fblocks -fconstant-string-class=NSConstantString -I. -I/home/simon/GNUstep/Library/Headers -I/usr/local/include \
        -o obj/bleetd.obj/bleetd/classes/server/Server.m.o
In file included from bleetd/classes/server/Server.m:10:
In file included from bleetd/classes/websockets/PSWebSocketServer.h:16:
bleetd/classes/websockets/PSWebSocket.h:69:1: error: property with 'retain (or strong)' attribute must be of object type
@property (nonatomic, strong) dispatch_queue_t delegateQueue;
In file included from bleetd/classes/server/Server.m:10:
bleetd/classes/websockets/PSWebSocketServer.h:47:1: error: property with 'retain (or strong)' attribute must be of object type
@property (nonatomic, strong) dispatch_queue_t delegateQueue;
2 errors generated.

The GNUmakefile I put together looks like:

---8<------8<------8<---  Cut Here  ---8<------8<------8<---

include $(GNUSTEP_MAKEFILES)/common.make

TOOL_NAME = bleetd
bleetd_CPPFLAGS         = -Ibleetd/classes/server \
bleetd_OBJC_FILES         = $(shell find bleetd -name '*.m')

include $(GNUSTEP_MAKEFILES)/tool.make

---8<------8<------8<---  Cut Here  ---8<------8<------8<---

So the question: Would I normally expect a 'dispatch_queue_t' to still be something that can be put into a property in GNUstep ? I'm really only familiar with the Mac side of things - I’m new to GNUstep, and in Mac-land they're reference-counted objects. I guess I’m asking: is this a bug, did I do something wrong during install, or is it expected behaviour ?


Discuss-gnustep mailing list

reply via email to

[Prev in Thread] Current Thread [Next in Thread]