similar to: [LLVMdev] [PATCH] BlocksRuntime updates for Linux

Breaks Builds on Solaris and AuroraUX with: bash-3.2$ make Scanning dependencies of target BlocksRuntime [ 1%] Building C object BlocksRuntime/CMakeFiles/BlocksRuntime.dir/runtime.c.o /export/home/edward/lab/llvm/build/compiler-rt/BlocksRuntime/runtime.c:77:2: error: #error unknown atomic compare-and-swap primitive /export/home/edward/lab/llvm/build/compiler-rt/BlocksRuntime/runtime.c: In

Sounds like your system compiler doesn't support gcc-style builtin atomics. Please use a different compiler? Shantonu Sent from my MacBook On Sep 22, 2009, at 7:54 PM, Edward O'Callaghan wrote: > Breaks Builds on Solaris and AuroraUX with: > > bash-3.2$ make > Scanning dependencies of target BlocksRuntime > [ 1%] Building C object

No, As it worked fine before. I can't see the #if that goes with +#elif defined(__WIN32__) as you removed -#if TARGET_OS_MAC. Please go over your #if / #endif blocks and trail the #endif with a comment. I am willing to bet there is a problem there. Thanks for your time, Edward. 2009/9/23 Shantonu Sen <ssen at apple.com>: > Sounds like your system compiler doesn't support

Seems pretty clear cut to me. #if defined(HAVE_OSATOMIC_COMPARE_AND_SWAP_INT) && defined (HAVE_OSATOMIC_COMPARE_AND_SWAP_LONG) ... #elif defined(__WIN32__) ... #elif defined(HAVE_SYNC_BOOL_COMPARE_AND_SWAP_INT) && defined (HAVE_SYNC_BOOL_COMPARE_AND_SWAP_LONG) ... #else #error unknown atomic compare-and-swap primitive #endif The problem isn't mismatched #if/#endif. The

Clang does indeed built it with one warning. [ 55%] Building C object lib/CMakeFiles/CompilerRT-Common.dir/gcc_personality_v0.c.o /export/home/edward/lab/llvm/build/compiler-rt/lib/gcc_personality_v0.c:232:36: warning: implicit declaration of function '__builtin_eh_return_data_regno' is invalid in C99 [-Wimplicit-function-declaration] _Unwind_SetGR(context,

There's an Apple internal bug for that. I've cloned it to Bugzilla as: <http://llvm.org/bugs/show_bug.cgi?id=5034> Implement __builtin_eh_return_data_regno() I can probably make the cmake configure stage fail up front if none of the supported mechanisms are found. I'll look at that. Thanks for the feedback! Shantonu Sent from my MacBook On Sep 22, 2009, at 9:01 PM,

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

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

I'm creating a binary package of compiler-rt for Debian and have a question about the build process. I followed the instructions on the compiler-rt homepage and built compiler-rt under Linux, but the 'make install' target only installs the following three files: -- Installing: /usr/local/lib/libBlocksRuntime.so -- Installing: /usr/local/include/Block.h -- Installing:

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

Óscar, Thanks for the help. I think I'm closer now ... hopefully; although I'm still getting the same error. The "gcc -v" output looks very similar to yours now. Do you see any other obvious configuration issues? I don't know what to try next.... $ ~/Desktop/Build/JamCloud/JamCloudServer$ gcc -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with:

When trying to link more than one object files compiled with clang, I run into errors of the following type: $ clang -fblocks -g -I$HOME/opt/include -L$HOME/opt/lib/ -o helloworld helloworld.c hello.o world.o -lBlocksRuntime world.o: In function `gnu_dev_major': /usr/include/sys/sysmacros.h:43: multiple definition of `gnu_dev_major' hello.o:/usr/include/sys/sysmacros.h:43: first defined

Curtis Jones <curtis.jones at gmail.com> writes: > Thanks for the help. I think I'm closer now ... hopefully; although > I'm still getting the same error. The "gcc -v" output looks very > similar to yours now. Do you see any other obvious configuration > issues? I don't know what to try next.... [snip] > /tmp/cc.o:(.rodata+0x0): undefined reference to

On 14/12/09 13:57, Abhishek Kulkarni wrote: > When trying to link more than one object files compiled with clang, I run into > errors of the following type: > > $ clang -fblocks -g -I$HOME/opt/include -L$HOME/opt/lib/ -o helloworld > helloworld.c hello.o world.o -lBlocksRuntime > world.o: In function `gnu_dev_major': > /usr/include/sys/sysmacros.h:43: multiple definition

[ resending after subscribing ] I would like to be able to compile and link the following two program into native executables. These are a vastly reduced testcase, so ignore for a moment the fact that the native compiler driver might have default -L/-F search paths and -lSystem by default. $ cat test1.c extern char *zlibVersion(void); extern int puts(char *); int main(int argc, char

Hi, Attached is small patch (based of r122998 of compiler-rt), required for clean builds on Solaris 10 / x86 using clang 2.8. Please consider it for inclusion. Cheers, Joakim -------------- next part -------------- A non-text attachment was scrubbed... Name: solaris_stdint.patch Type: application/octet-stream Size: 457 bytes Desc: not available URL:

I've reattached the patch to runtime.c, this time as output from svn instead of git. As the original git commit noted, it does the following: define OSAtomicCompareAndSwap(Long|Int) for non-Mac/Win32 systems if neither TARGET_OS_MAC or TARGET_OS_WINDOWS are defined, check to see if GCC atomic built-ins are available (and use them if they are). yours, Bobby On Sat, Sep 12, 2009 at 3:24 AM,

Hi Folks, The attached patches gets the Blocks runtime built and installed on my Linux system. Let me know if the patches are okay as is, or what I need to do to get them merged into compiler-rt. Thanks! yours, Bobby Powers -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-define-OSAtomicCompareAndSwap-Long-Int-for-non-Mac-W.patch Type: text/x-patch Size:

Some low-priority fixes to the build system.... These can probably wait after 2.2 1) The current configure script checks for gcc 3.x or later by parsing "gcc --version" output and trying to tokenize it to find the major compiler version. This is pretty fragile and interacts poorly with compilers produced by vendors (like Apple) that modify this string to output target triple

doesn't --target=x86_64-apple-darwin imply you don't want multi-libs, and an x86_64-only compiler? Shantonu Sent from my MacBook On Aug 23, 2009, at 11:36 AM, Jack Howarth wrote: > Current llvm-gcc-4.2 for trunk and the 2.6 release > is unable to build the i386 multilib for the > x86_64-apple-darwin target. The attached patch provides > this support. Can we get this into