llvm dev - Sep 2009 - [LLVMdev] Status of blocks runtime in compiler-rt?

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).

Shantonu

Sent from my MacBook

On Sep 15, 2009, at 4:42 PM, Edward O'Callaghan wrote:
> 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
> also.)
>
> 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.
>
> Cheers,
> Edward O'Callaghan.
>
> 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.
>>
>> Thanks!
>>
>> - Jordan
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>
>
>
> -- 
> -- 
> Edward O'Callaghan
> http://www.auroraux.org/
> eocallaghan at auroraux dot org
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

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 <http://llvm.org/docs/CMake.html 
 >

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

1) Install cmake (<http://www.cmake.org/>), 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
   Block_release(copyPrintXAndY);

   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
ssen at apple.com

Sent from my Mac Pro

On Sep 16, 2009, at 8:00 AM, Shantonu Sen wrote:
> 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).
>
> Shantonu
>
> Sent from my MacBook
>
> On Sep 15, 2009, at 4:42 PM, Edward O'Callaghan wrote:
>
>> 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
>> also.)
>>
>> 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.
>>
>> Cheers,
>> Edward O'Callaghan.
>>
>> 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.
>>>
>>> Thanks!
>>>
>>> - Jordan
>>>
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>>
>>
>>
>>
>> -- 
>> -- 
>> Edward O'Callaghan
>> http://www.auroraux.org/
>> eocallaghan at auroraux dot org
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

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 at fuzzy ~/Src/llvm/tools/compiler-rt/build]$ pwd
/home/jkh/Src/llvm/tools/compiler-rt/build
[jkh at fuzzy ~/Src/llvm/tools/compiler-rt/build]$ ls
[jkh at 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):
   CMakeLists.txt:18 (MACRO_ENSURE_OUT_OF_SOURCE_BUILD)


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):
   CMakeLists.txt:18 (MACRO_ENSURE_OUT_OF_SOURCE_BUILD)


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

On Sep 21, 2009, at 6:21 PM, Shantonu Sen wrote:
> 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
<http://llvm.org/docs/CMake.html
> >
>
> More specifically, to use this support on FreeBSD, for example, you  
> would do:
>
> 1) Install cmake (<http://www.cmake.org/>), 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
>  Block_release(copyPrintXAndY);
>
>  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
> ssen at apple.com
>
> Sent from my Mac Pro
>
> On Sep 16, 2009, at 8:00 AM, Shantonu Sen wrote:
>
>> 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).
>>
>> Shantonu
>>
>> Sent from my MacBook
>>
>> On Sep 15, 2009, at 4:42 PM, Edward O'Callaghan wrote:
>>
>>> 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
>>> also.)
>>>
>>> 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.
>>>
>>> Cheers,
>>> Edward O'Callaghan.
>>>
>>> 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.
>>>>
>>>> Thanks!
>>>>
>>>> - Jordan
>>>>
>>>> _______________________________________________
>>>> LLVM Developers mailing list
>>>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>>>
>>>
>>>
>>>
>>> -- 
>>> -- 
>>> Edward O'Callaghan
>>> http://www.auroraux.org/
>>> eocallaghan at auroraux dot org
>>>
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>

On Sep 21, 2009, at 6:21 PM, Shantonu Sen wrote:
> I've committed my changes to hook up the BlocksRuntime/ subdirectory  
> of compiler-rt, using CMake.
>
> The cmake build process is documented at
<http://llvm.org/docs/CMake.html
> >
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

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20090922/df09d466/attachment.html>