Skip to content


Subversion checkout URL

You can clone with
Download ZIP


Support GNUstep blocks runtime #2

LubosD opened this Issue · 10 comments

3 participants



GNUstep's libobjc2 runtime provides blocks support as well. It would be nice if this worked with your tree out of box. This is what I need to do to get things working:

LIBS="" CFLAGS="-D__BLOCKS__ -O2 -fblocks" ./configure

(-D__BLOCKS__ may not be needed, I added that just to be sure).

then you need to replace

#include <Block_private.h>
#include <Block.h>

with this:

#include <objc/blocks_runtime.h>
#include <objc/blocks_private.h>

Given that libdispatch is most likely to be used by cross-platform apps, it is very likely that it's users will have GNUstep installed when on Linux.


Hi Lubos,

I'm not familiar with GNUStep, and I'm not even terribly familiar with the Autotools build system that libdispatch uses, but I should have time to look into this in a few weeks.

In the meantime, you're welcome to submit a pull request.



Yeah, I hate Autotools too :-( Never really managed to do anything useful with it.


You could include a script that will make symlinks to "pose" GNUstep libobjc2 as libBlockRuntime as well as required header files. I will fork this project to do all the needed changes. This will break the requirement of libBlocksRuntime (or clang's compiler-rt) but add requirements of GNUstep-make and GNUstep's libobjc2.


Well because the blocks ABI is a bit different between GNUstep and Apple.

Apple used their C-level CoreFoundation technologies to implement blocks but GNUstep used GSBlock, an Objective-C class.

Simpler cross-use the ABI is okay, but when any copying is involved, the difference in ABI will break the program and corrupt memory structure.


Ah okay, that's interesting. Is this ABI difference documented anywhere?


I have no idea, but I know the API is identical. So pretty much it is link-against thing. Just drop the libBlocksRuntime header files and library and use libobjc2 ones.


The ABI of GNUstep's Blocks should be identical to Apple's Blocks. I don't know why they chose different header file names, but now that you've switched to CMake, it should be much easier to support it.

See for the patch I currently use.


So I think the best way forward is to use the same approach as GNUstep: weak linking.

  1. Copy the needed Blocks header files or just declarations into your project. Add __attribute__((weak)) to all function declarations. You may want to use some macros so that you don't apply this attribute on Windows, where weak linking is not possible.
  2. Forget about libBlocksRuntime or any other runtime, do not include any external header files for Blocks.
  3. Do not link to any specific Blocks runtime.
  4. Everything will work nicely.

Explanation - there are only two situations possible:

  • The user of your library doesn't use blocks in his code. Therefore he doesn't use any of the block-accepting functions within libdispatch. Hence the weak references (being NULL at this time) are never used. The user is also not forced to install any Blocks runtime.
  • The user of your library uses blocks. Because of that he links to some kind of Blocks runtime and weak refs within libdispatch point to symbols in that runtime. The user is not forced to use any specific runtime.
This was referenced
@nickhutchinson nickhutchinson added this to the 0.2 milestone
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.