[LLVMdev] Status of blocks runtime in compiler-rt?
eocallaghan at auroraux.org
Tue Sep 15 16:42:37 PDT 2009
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
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.
2009/9/15 Jordan K. Hubbard <jkh at apple.com>:
> Hi folks,
> So, various folks are in the process of porting Grand Central Dispatch
> to FreeBSD (c.f. http://libdispatch.macosforge.org and http://lists.macosforge.org/pipermail/libdispatch-dev
> 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 http://www.opensource.apple.com/source/gcc/gcc-5646
> 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
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
eocallaghan at auroraux dot org
More information about the llvm-dev