A clone of the compiler-rt library (http://compiler-rt.llvm.org/) but only the BlocksRuntime library portion. (Actually the compiler-rt master subversion source repository at http://llvm.org/svn/llvm-project/compiler-rt has an automatic git mirror at http://llvm.org/git/compiler-rt.git the refs/heads/master of which is cloned into refs/heads/compiler-rt of this repository.)

In addition to the clone of the BlocksRuntime library sources, a config.h file, testprefix.h file, a sample.c file and a few convenient shell scripts have been added in order to build, test and install the Block.h header and libBlocksRuntime.a library without needing cmake or make.

Any system which has a version of the clang compiler (either pre-installed or installable via any mechanism) with support for the -fblocks option should be supported.

In particular, the FreeBSD, Linux, MacPorts and mingw versions of clang are known to work with the blocks runtime.
Your system may already come with the BlocksRuntime library pre-installed or installed as part of the clang package. And furthermore, it may not require linking with any special library to use it either. See the Do I Need This? section for a way to check.

Why?

you get a linker error something about an undefined __NSConcreteGlobalBlock symbol so you try:

clang -o sample -fblocks sample.c -lBlocksRuntime

but then you get a linker error about ld: library not found for -lBlocksRuntime instead.
This repository can help you build the libBlocksRuntime.a library very easily so that you can successfully use the Blocks language extension supported by the -fblocks option of the clang compiler.

If you do NOT get any kind of error output then your installation of clang already provides the
Blocks runtime support via the -lBlocksRuntime library option and you have no need for
this library (which provides the same thing).

If you got to this step then yes, you do need this library if you want to use the Blocks support
available with your installation of the clang compiler.

GNU C Library (glibc) Problem

This issue is typically seen on Linux systems that use glibc. Older glibc releases contains a posix/unistd.h header file which typically ends up installed as /usr/include/unistd.h and contains this declaration:

Unfortunately when compiling with the -fblocks option __block cannot be used as a formal parameter name.
This issue was fixed in glibc as of commit 84ae135d3282dc362bed0a5c9a575319ef336884 on 2013-11-21 and first appeared in the glibc-2.19 release on 2014-02-07. Since ldd is part of glibc the currently installed version of glibc can be checked using ldd like so:

ldd --version

If the source file being compiled needs to use the -fblocks option and also #include <unistd.h> from an older version of glibc (prior to glibc-2.19) then there are two options:

Change the formal parameter name in the /usr/include/unistd.h header from __block to something else such as __glibc_block (or anything else so long as it’s not __block)

Use the workaround from the testprefix.h header file which temporarily undefines __block includes the unistd.h header and then redefines __block:

Note that this example tests the __linux__ preprocessor macro, but that is not necessarily a reliable check for the problem since glibc could be in use without __linux__ being defined although in practice this seems to work fine.

Basically the Blocks language extension adds closure support
to the C/Objective-C/C++/Objective-C++ languages. If you are familiar with the Smalltalk programming
language, the Blocks language extensions provides something very similar to Smalltalk code blocks.
Here's the sample.c file from this repository:

In the above sample code, both block and block2 are block variables. And while i is an integer variable, the optional __block storage class language extension modifies i's behavior when it's accessed from within a block.