similar to: [LLVMdev] Problem in LLVM CMake modules

Eli Gottlieb <eligottlieb at gmail.com> writes: > 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

After I actually get everything compiling, install the library, and load it from my Java program, I get the following: > Exception in thread "main" java.lang.UnsatisfiedLinkError: > /usr/lib/libjllvm.so: /usr/lib/libjllvm.so: undefined symbol: > _ZTVN10__cxxabiv120__si_class_type_infoE If I have to guess, this means that the CMake stuff given is linking to the C++ libraries

So where could I find a list of LLVM libraries so I can figure out which ones I actually need to link into my program? Oscar Fuentes <ofv at wanadoo.es> writes: > Óscar Fuentes <ofv at wanadoo.es <http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev>> writes: > > >/ This patch *seems* to fix the problem (cmake regexps are not thoroughly > />/ documented): >

Eli Gottlieb <eligottlieb at gmail.com> writes: > So you're saying that the default CMake build of LLVM creates static > libraries that got linked into my shared-object and now require me to > link in everything they require myself? Shouldn't the linker be able > to track down C++ runtime for this? You told CMake to manage your shared library as if it were a pure C

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

On Nov 4, 2010, at 11:48 AM, Óscar Fuentes wrote: > Eli Gottlieb <eligottlieb at gmail.com> writes: > >> So you're saying that the default CMake build of LLVM creates static >> libraries that got linked into my shared-object and now require me to >> link in everything they require myself? Shouldn't the linker be able >> to track down C++ runtime for

Hi again, 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 it just runs forever (while still responding to a CTRL-C): > eli at

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

Eli Gottlieb <eligottlieb at gmail.com> writes: > The two lines >> set(CMAKE_MODULE_PATH ${CMAKE_MODULE_PATH} >> "${LLVM_ROOT}/share/llvm/cmake") >> include(LLVM) > don't seem to work. I'm checking with installing LLVM from source to > see if that makes it work, but the LLVM install from the Ubuntu repos > doesn't seem to have a

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 Sat, Mar 20, 2010 at 7:54 PM, Óscar Fuentes <ofv at wanadoo.es> wrote: > It doesn't *recommend* running cmake in-source. It is just that the > instructions are written that way. When generating VS solution files, > building in-source is not a problem. It is when generating makefiles, as > the generated makefiles will overwrite those provided with LLVM's > sources.

On Sun, Sep 21, 2008 at 9:27 AM, Óscar Fuentes <ofv at wanadoo.es> wrote: > This is an updated version of the patch that fixes some issues on VC++ > builds. Hi, FYI I just tried this (from r56534). I get an "error" (below) from cmake (2.6.1) about Intrinsics.gen but it seems to write out sln/vcproj anyway. Project.sln opens and builds OK (modulo a build error in llvmc2

Hello. When i run llvm-config --libs jit bitreader bitwriter ipo linker engine i get: -lLLVMX86Disassembler -lLLVMX86AsmParser -lLLVMX86CodeGen -lLLVMSelectionDAG -lLLVMAsmPrinter -lLLVMMCParser -lLLVMX86AsmPrinter -lLLVMX86Utils -lLLVMX86Info -lLLVMLinker -lLLVMArchive -lLLVMipo -lLLVMBitWriter -lLLVMBitReader -lLLVMJIT -lLLVMExecutionEngine -lLLVMCodeGen -lLLVMScalarOpts -lLLVMInstCombine

I have a directory dumps on my laptop containing several dumps of various levels. local-0-2007-03-03.gz local-4-2007-02-12.gz local-4-2007-02-19.gz local-4-2007-02-26.gz local-4-2007-03-05.gz local-5-2007-03-04.gz local-5-2007-03-06.gz local-5-2007-03-07.gz local-5-2007-03-08.gz Naturally the level-0 is the largest and rarely changes. On the target (access.cims.nyu.edu) I have a directory

IMHO, the CMake-based build system is almost complete enough to replace current MSVC++ project files (modulo some community review and bug-fixing). Is this enough for adding it to the LLVM repo? >From the point of view of a MSVC++ user, the new build system is trivial to maintain: you can add a new library or tool executable in less time that it takes to open the project file on MSVC++, it

Zitat von Israel Gottlieb <isrlgb at gmail.com>: > If you the c option in the dial command it will send answered > else where sip message to the phone and most ip phones understand that > The cell will always display a missed call? I'm very sorry, but I can't understand what you mean... Could you explain, maybe with an example? Thanks Luca Bertoncello (lucabert at

This is an updated version of the patch that fixes some issues on VC++ builds. -- Oscar -------------- next part -------------- A non-text attachment was scrubbed... Name: cmake.patch Type: text/x-patch Size: 73590 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20080921/687284b5/attachment.bin>

On 5/14/2012 10:28 AM, Jim Grosbach wrote: > > On May 14, 2012, at 10:21 AM, Ashok Nalkund<ashoknn at qualcomm.com> wrote: > >> On 5/14/2012 9:51 AM, Jim Grosbach wrote: >>> >>>>> >>>>> If you're hitting that code, you're running the old JIT (which does indeed not support inline assembly), not the MCJIT. >>>>>

Hi, Using the trunk of svn. I'm trying to get inline-asm working on X86. So I added call to: > InitializeNativeTargetAsmParser() during initialization. However, this causes a linking error: > llvm[2]: Linking Debug+Asserts executable lli > /local/mnt/workspace/ashoknn/crd/neo/llvm/proto/llvmsvn/build/tools/lli/Debug+Asserts/lli.o: In function