similar to: [LLVMdev] Problem in LLVM CMake modules

Eli Gottlieb <eligottlieb at gmail.com> writes: > I'm trying to upgrade my LLVM bindings in Java from 2.9 to 3.1. To > do so, I regenerated the JNI bindings from fresh LLVM 3.1 headers, and > did a slight rewrite of my CMakeLists.txt file for building the C > code. > > Problem is, cmake no longer finishes at all. I receive the > following output, and then

[Please CC the mailing list] Eli Gottlieb <eligottlieb at gmail.com> writes: > OK, I'm just going to paste in my CMakeLists.txt file. Like I said, > I'm building an LLVM install myself by untarring llvm, mkdir build in > the root dir of the source, cd build/, cmake .., make. > >> cmake_minimum_required (VERSION 2.6) >> project (libjllvm) >>

I compiled and installed it to the prefix /usr, but that's not the issue. Once I actually compile and install LLVM with CMake by hand, I get the share/llvm/cmake stuff installed correctly (can those files be included in "normal" builds, or will LLVM switch to CMake as its primary build system?). Now I'm running into the problem of cflags or includes or something not being

Óscar Fuentes <ofv at wanadoo.es> writes: > Yep, llvm_map_components_to_libraries gets confused by the existence of > both gtest and gtest_main and enters an infinite loop. A workaround is > to not pass "all" to llvm_map_components_to_libraries but a list of > required components. This patch *seems* to fix the problem (cmake regexps are not thoroughly documented):

On Tue, Oct 9, 2012 at 9:25 PM, Jun Koi <junkoi2004 at gmail.com> wrote: > On Fri, Oct 5, 2012 at 3:45 PM, Jun Koi <junkoi2004 at gmail.com> wrote: >> On Fri, Oct 5, 2012 at 3:39 PM, David Chisnall >> <David.Chisnall at cl.cam.ac.uk> wrote: >>> On 5 Oct 2012, at 08:34, Jun Koi wrote: >>> >>>> any idea on how to fix the problem?

Dear all, I am trying to move a project from Linux to OSX, with bad results at my first attempt. First, I am using LLVM 3.2, the latest version, compiled from sources (configured with just the install prefix, vanilla for other options). By the way, I found it annoying to reinstall LLVM, I expected a complete and working LLVM environment with Apple's move to CLANG, but maybe I didn't

On 1/19/2013 2:39 AM, Óscar Fuentes wrote: > Ashok Nalkund <ashoknn at qti.qualcomm.com> writes: > >> We want to compile LLVM/Clang and use the resulting >> headers/libraries in our project. But we compile it during out build >> process. I can build LLVM/Clang by adding it to our cmakelists.txt but >> when our code tries to use one of the headers >>

Greetings, I have a simple C++ EDSL working using the JIT execution engine. When I upgraded to LLVM 3.2 (effortless upgrade, awesome stuff!) I thought I would try taking the MCJIT for a spin after having read that the JIT is considered to be "legacy". So the changes I made to my code were: + #include <llvm/ExecutionEngine/MCJIT.h> - #include <llvm/ExecutionEngine/JIT.h> +

On 1/21/2013 2:01 AM, Óscar Fuentes wrote: > Ashok Nalkund <ashoknn at qti.qualcomm.com> writes: > >> I was using the find_package(LLVM llvm/share/llvm/cmake) and >> llvm_map_components_to_libraries(REQ_LLVM_LIBRARIES jit native) to get >> the libraries to link against. This works well for the libLLVM* >> libraries, but how do I implement similar find stuff for

Ashok Nalkund <ashoknn at qti.qualcomm.com> writes: > I was using the find_package(LLVM llvm/share/llvm/cmake) and > llvm_map_components_to_libraries(REQ_LLVM_LIBRARIES jit native) to get > the libraries to link against. This works well for the libLLVM* > libraries, but how do I implement similar find stuff for clang > libraries? AFAIK, there is no such feature for Clang.

On 1/21/2013 10:25 AM, Ashok Nalkund wrote: > On 1/21/2013 2:01 AM, Óscar Fuentes wrote: >> Ashok Nalkund <ashoknn at qti.qualcomm.com> writes: >> >>> I was using the find_package(LLVM llvm/share/llvm/cmake) and >>> llvm_map_components_to_libraries(REQ_LLVM_LIBRARIES jit native) to get >>> the libraries to link against. This works well for the

This is just standard behavior of the Python interpreter. The files are just a cache (it is not the sources being modified) and also won't be written if the source tree is made read only, and shouldn't cause a problem in practice. - Daniel On Jan 22, 2013, at 0:02, Duncan Sands <baldrick at free.fr> wrote: > I would have expected the .pyc files to go in the objects directory.

On Fri, Oct 5, 2012 at 3:45 PM, Jun Koi <junkoi2004 at gmail.com> wrote: > On Fri, Oct 5, 2012 at 3:39 PM, David Chisnall > <David.Chisnall at cl.cam.ac.uk> wrote: >> On 5 Oct 2012, at 08:34, Jun Koi wrote: >> >>> any idea on how to fix the problem? >> >> The correct solution is to fix the LLVM build to install the .cmake files in a location that

On Fri, Oct 5, 2012 at 3:39 PM, David Chisnall <David.Chisnall at cl.cam.ac.uk> wrote: > On 5 Oct 2012, at 08:34, Jun Koi wrote: > >> any idea on how to fix the problem? > > The correct solution is to fix the LLVM build to install the .cmake files in a location that CMake knows about. could you please elaborate? > The hacky solution that I've used is just to copy

Hi, Zhao > I have checked out llvm 2.9. There is only one CMakeLists file in Release or svn? I believe Nick has committed those CMake files into svn. You can apply my patch to LVM 2.9 Release. > "\llvm-2.9". and no CMakeLists file in folder either > "\llvm-2.9\runtime\libprofile" or "\llvm-2.9\runtime". Where did you get it? As Nick said, libprofile

Ashok Nalkund <ashoknn at qti.qualcomm.com> writes: > We want to compile LLVM/Clang and use the resulting > headers/libraries in our project. But we compile it during out build > process. I can build LLVM/Clang by adding it to our cmakelists.txt but > when our code tries to use one of the headers > (clang/CodeGen/ModuleBuilder.h), its not found as it doesnt exist. If > I

Hello, I am generating profile_rt.dll by perfoming 'make' in $LLVM_SRC_DIR/runtime/libprofile. After make, I got the following error messages. llvm[0]: Linking Debug+Asserts Loadable Module profile_rt.dll /usr/lib/gcc/i686-pc-cygwin/4.3.4/../../../../i686-pc-cygwin/bin/ld:/cygdrive/c/ llvm/runtime/libprofile/Debug+Asserts/exported_symbols.lst: file format not reco gnized; treating as

Hi, Thanks for the replies in the mailing list. I made some progress in building LLVM, but I still have a problem about ELF class. I am working with LLVM on a sparcv9 machine, while the gcc is configured to emit 32-bit binary by default. After executing "configure --with-llvmgccdir=... --enable-jit", I modified Makefile.config so it contains CXX = g++ -mcpu=v9 -m64 CC := gcc -mcpu=v9

*System:* Debian Linux Sid/Unstable amd64 *LLVM/Clang:* Trunk *Scenario:* In the past couple of days I've been compiling against trunk I get two separate and spurious hang ups with CMake. *Note:* I build against more than just X86 follow along the progress of other platforms, though just building for X86 produces the same results below. *Assumption:* Configure cmake with prior built

Dear all, I want to build an LLVM pass by using CMake. After reading the ralevant part of the documentation ( http://llvm.org/releases/3.1/docs/CMake.html#passdev), I copied the files in the llvm/lib/Transforms/Hello to another folder in order to give a try. Then I renamed the folder as Hello2. Then I have changed CMakeLists.txt as following: cmake_minimum_required(VERSION 2.8) # A