Status of blocks runtime in compiler-rt?

Hi folks,

So, various folks are in the process of porting Grand Central Dispatch to FreeBSD (c.f. and for mailing list discussion on the topic) and are making good progress, but one of the issues they're running into is support for Blocks in FreeBSD.

On the one hand, they could try and back-port the gcc changes from and solve the problem that way or, on the other hand, they could just continue FreeBSD's inexorable march towards Clang and get the blocks support as part of compiler-rt. The only problem seems to be that the build support for Blocks in compiler-rt isn't wired up yet, which came as something of a surprise to all involved given that people have been talking about Clang and Blocks since this summer.

Is there a roadmap for this anywhere that we can read? If this simply has not been done due to a lack of resources, the GCD porting folks could perhaps help move this along, assuming they had appropriate access to the bits.


- Jordan

Good day,

I been working on the CMake build system (which is nice and portable)
+ code clean ups over the whole Compiler-RT software suit.
I recently added Blocks to the CMake build system but there is some
ugly looking warnings I need to fix up in the Blocks code which I have
not had time to look into yet.
N.B. The CMake build system is not complete yet due to my lack of
time, however I am still active, help really welcome !

My main goal is to have Compiler-RT as a highly portable runtime that
will build and run on AuroraUX, *BSD, Linux and OSX with lint clean
code and zero build warnings. Also, I plan to add SPARC support in the
near future if I get time. (As I work on AuroraUX almost full time

These are my personal goals working on Compiler-RT.

Could you please outline *exactly* what you would like to see happen
with Blocks,
I don't really know much about Blocks to be fair however I would be
interested to hear and at least it would be 'on record' here.

Edward O'Callaghan.

The Blocks language and implementation specifications are checked into clang/docs.

More generally, on Mac OS X, the blocks runtime is linked into the C library ("libSystem"), and available to the entire OS. Clients that create blocks may implicitly get compiler-generated calls to some of the runtime functions, and the developer may also make explicit calls to, e.g., Block_copy().

On other OSes, the library would need to be built and installed somewhere. There's also the question of whether it should be a shared library or static library. I can see both points, but think that a shared library is probably the right way for it.

It should probably be generally portable (it doesn't appear to compiler correctly with llvm-gcc and clang on Linux), and install its headers (doesn't appear to).

I can spend some time on this, since I have some familiarity with libdispatch (Apple's APIs that heavily use Blocks for developer convenience).


Hi Jordan,

I've committed my changes to hook up the BlocksRuntime/ subdirectory of compiler-rt, using CMake.

The cmake build process is documented at < >

More specifically, to use this support on FreeBSD, for example, you would do:

1) Install cmake (<>), add it to your PATH
2) Check out the source code for llvm and clang
3) Build it with cmake, using:
$ mkdir build
$ cd build
$ env CC="cc -march=i686" CXX="c++ -march=i686" cmake -DCMAKE_INSTALL_PREFIX=$PREFIX ..
$ make
$ make install

4) Check out the source code for compiler-rt
5) Build it, optionally with clang, although this isn't strictly required. You can use the system gcc too, like in step 3.
$ mkdir build
$ cd build
$ env CC="clang" CXX="c++ -march=i686" cmake -DCMAKE_INSTALL_PREFIX=$PREFIX ..
$ make
$ make install

Simple programs seem to work at that point for me:
$ cat foo.c
#include <stdio.h>
#include <stdlib.h>
#include <Block.h>

int main(int argc, char *argv[]) {

   int x = 123;

   void (^printXAndY)(int) = ^(int y) {
     printf("%d %d\n", x, y);
   void (^copyPrintXAndY)(int) = Block_copy(printXAndY);

   copyPrintXAndY(456); // prints: 123 456

   return 0;

$ clang -I$PREFIX/include -fblocks -c foo.c
$ clang -L$PREFIX/lib -Wl,-rpath,$PREFIX/lib -o foo foo.o -lBlocksRuntime
$ ./foo
123 456

I've also tried similar steps on Ubuntu Linux, as well as with llvm-gcc-4.2, which also worked.

Shantonu Sen

Hmmm. Something seems to be amiss. I've got both LLVM and clang installed OK, but when I go to do the cmake steps in an empty build subdirectory of compiler-rt, cmake blows up in a way which suggests I'm still not using it right. Not a cmake user, really, so I'm not sure what to do next..

[jkh@fuzzy ~/Src/llvm/tools/compiler-rt/build]$ pwd
[jkh@fuzzy ~/Src/llvm/tools/compiler-rt/build]$ ls
[jkh@fuzzy ~/Src/llvm/tools/compiler-rt/build]$ env CC="cc -march=i686" CXX="c++ -march=i686" cmake -DCMAKE_INSTALL_PREFIX=/usr/local ..
CMake Error at cmake/Modules/MacroEnsureOutOfSourceBuild.cmake:7 (message):
   CompilerRT requires an out of source build. Please create a separate build
   directory and run 'cmake /path/to/CompilerRT [options]' there.
Call Stack (most recent call first):

CMake Error at cmake/Modules/MacroEnsureOutOfSourceBuild.cmake:8 (message):
   In-source builds are not allowed.

    CMake would overwrite the makefiles distributed with Compiler-RT.
    Please create a directory and run cmake from there, passing the path
    to this source directory as the last argument.
    This process created the file `CMakeCache.txt' and the directory `CMakeFiles'.
    Please delete them.
Call Stack (most recent call first):

-- Configuring incomplete, errors occurred!
[jkh@fuzzy ~/Src/llvm/tools/compiler-rt/build]$

Whoops, looks like the presence of a CMakeFiles directory in the SRCROOT was screwing things up, even when I was in a build subdirectory. Blowing that away has everything humming away properly now.

Yep, just got my blocks “hello world!” example to work on FreeBSD 9-current! Success!

Now to figure out just where to stick this so it’s as pervasively available on FreeBSD as it is on Mac OS X. Libc? Really?

  • Jordan

I think you can either use the Apple approach (libSystem which contains libc, libdispatch, asl, block runtime, libgcc and other APIs) or the way it works previously, a separate library that the compiler links automatically like libgcc_s.

– Jean-Daniel

One option I am thinking about pursuing in the near term is better
support (build system and driver) for installing a compiler-rt (as a
private compiler support library) and teaching clang to link with
that. Once that work is done at least for clang it wouldn't have to be
in libc. Eventually one might want it to, to avoid carrying around
static copies of the runtime implementation, but that is a much lower
priority QOI issue than "having it work".

Presumably if that is done for clang it wouldn't be too difficult to
have make the llvm-gcc driver know how to link in the compiler-rt
static library as well.

- Daniel