[LLVMdev] Status of blocks runtime in compiler-rt?
Jordan K. Hubbard
jkh at apple.com
Tue Sep 22 10:55:27 PDT 2009
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
>
More information about the llvm-dev
mailing list