similar to: [LLVMdev] Problem initializing a JIT via C bindings

Keppler, Dave wrote: > Hi all, > > I have some code that uses the x86 JIT via the C bindings that I'm trying to migrate from targeting LLVM 2.5 to the top of tree, but I'm running into a linking problem I can't figure out. > > Here's how I'm invoking the JIT in 2.5. > > LLVMInitializeNativeTarget(); <-- for the updated version >

>> I'm compiling it as follows, which completes with no errors on either >LLVM version. >> >> LLVM_CONFIG=<the llvm-config from the version I want to use> >> gcc `$LLVM_CONFIG --cflags` -o main.o -c main.c >> g++ `$LLVM_CONFIG --cflags` \ >> `$LLVM_CONFIG --ldflags` \ >> main.o `$(LLVM_CONFIG) --libfiles engine BitReader` >>

Hello, I'm using the llvm-c bindings for C, but I'm getting some problems, the LLVMCreateExecutionEngine is returning 1 but the error message is an empty string (it's !=NULL). The steps I'm doing is to create the module, then I call LLVMVerifyModule to verify and it works fine, later I call LLVMCreateModuleProviderForExistingModule and it returns !=NULL MP, so it's ok, but

On 11/14/2017, 01:26 AM, Chris Bieneman wrote: > Sorry for the delayed response. I've been out of town a lot lately. > > The documentation you referenced is unfortunately out of date (you might notice it still references autoconf). I'll see if I can find time to update it, but the guidance should be to use the `llvm_config` CMake function instead. The proper usage of that in the

On Fri, Dec 07, 2012 at 06:20:37PM +0100, Duncan Sands wrote: > Hi Jack, this occurs because you compiled LLVM with clang (right?) and > dragonegg is compiled with the same flags used to compile LLVM (it is > an llvm-config bug in my opinion that llvm-config output includes these > kinds of optional flags). Duncan, Yes. I believe both fink and MacPorts now default to the clang

Hi Jack, can you please open a bug report asking that llvm-config only provide the minimum set of flags needed to compile code that interfaces with LLVM, rather than (as now) all kinds of unneeded flags such as -g and warnings. Thanks, Duncan. On 07/12/12 18:55, Jack Howarth wrote: > On Fri, Dec 07, 2012 at 06:20:37PM +0100, Duncan Sands wrote: >> Hi Jack, this occurs because you

On 2009-01-19, at 13:50, Nick Lewycky wrote: > I have an issue with the OCaml build system and the ExecutionEngine. > > PR2128 has a patch to change the Interpreter to use libffi. This > breaks test/Bindings/Ocaml/executionengine.ml because OCaml doesn't > try to link with libffi, even though llvm-config knows that we should: > > $ Debug/bin/llvm-config --ldflags

Hi, On Sun, Aug 3, 2008 at 11:42 PM, Chris Lattner <clattner at apple.com> wrote: > > On Aug 3, 2008, at 7:54 AM, Mahadevan R wrote: > >> Hi, >> >> Just wondering -- shouldn't all (C linkage) functions exposed by >> LLVM-C (and written in C++) be catching std::exception (or "...") to >> prevent exceptions being passed on to C callers?

Hi Jack, this occurs because you compiled LLVM with clang (right?) and dragonegg is compiled with the same flags used to compile LLVM (it is an llvm-config bug in my opinion that llvm-config output includes these kinds of optional flags). Ciao, Duncan. On 07/12/12 18:11, Jack Howarth wrote: > Duncan, > I am unable to complile dragonegg 3.2 with FSF gcc 4.7 due the the > compiler

Hi Rehman, if I understand right the plugin works fine if you compile it with -fvisibility=hidden, and replace LLVM_GLOBAL_VISIBILITY in llvm-backend.cpp with __attribute__ ((visibility("default"))). Since LLVM_GLOBAL_VISIBILITY is a macro that expands to __attribute__ ((visibility("default"))) if you are not on mingw32 or cygwin, and your gcc version is at least 4, that

Duncan, I am unable to complile dragonegg 3.2 with FSF gcc 4.7 due the the compiler errors... GCC=/sw/lib/gcc4.7/bin/gcc-4 LLVM_CONFIG=/sw/opt/llvm-3.2/bin/llvm-config VERBOSE=1 ENABLE_LLVM_PLUGINS=1 make CPPFLAGS="-g -DENABLE_LTO -I/sw/include" /sw/lib/gcc4.7/bin/gcc-4 --version > /dev/null /sw/opt/llvm-3.2/bin/llvm-config --version > /dev/null Compiling utils/TargetInfo.cpp

Hi all, Sorry for the inconvenient about the previous post. The files were not attached. So I put them here again. I am a newbie in LLVM and I am trying to replace the function like: old function || new function ============================== ========= int haha(int a) { int haha(int a, char* ID) { ===> }

Good summer, all! This patch enables ENABLE_SHARED=1 to build DLL based LLVM toolchain. I have checked this on Cygwin-1.5, Cygwin-1.7, mingw(msysgit) and mingw-cross-fedora12. I can separate this patch into some parts; cleanups, adding definitions and adding rules. Any feedbacks are welcome. Have fun! ...Takumi * Pros - reduction of linking time of toolchain. - capability of -load

Hi llvm-dev, Attached are two patches for the LLVM cmake build system. The first one adds static runtimes (MT and MTd) to the list of runtimes for the MSVC build. The second one makes it possible to use llvm_config in external projects. In this patch I took the liberty of changing the format of LLVMLibDeps.cmake to define a single variable LLVM_LIB_DEPS instead of MSVC_LIB_DEPS_*.

Hi all, CMake seems to have broken in the last few days - or is it just me? tcare:llvm-release tcare$ make -j4 -- Target triple: x86_64-apple-darwin10.5.0 -- Native target architecture is X86 -- Threads enabled. -- Building with -fPIC -- Targeting X86 CMake Error at cmake/modules/LLVMConfig.cmake:90 (message): Library LLVMARMAsmParser not found in list of llvm libraries. Call Stack (most

Duncan, Many thanks for your comments. The core issue we're running into is this: $ GCC=/usr/bin/gcc LLVM_CONFIG=/usr/bin/llvm-config make Compiling utils/TargetInfo.cpp Linking TargetInfo ld: fatal: library -lLLVMSupport: not found ld: fatal: file processing errors. No output written to TargetInfo collect2: error: ld returned 1 exit statusAll other gyrations are attempts to shoehorn

Oops, missed initializing some stuff. Added: LLVMLinkInMCJIT(); LLVMInitializeNativeTarget(); LLVMInitializeNativeAsmPrinter(); LLVMInitializeNativeAsmParser(); Now it crashes in LLVMGetFunctionAddress(). Hmm. On Wed, Mar 8, 2017 at 5:14 PM, Toshiyasu Morita <toshi at tensyr.com> wrote: > Made it a bit further. Here's the current code: > >

Frits van Bommel skrev: > Benjamin Kramer wrote: > >> At the moment llvm-config outputs "2.6svn" if llvm is build from trunk >> >> $ llvm-config --version >> 2.6svn >> >> Some external projects (built out-of-tree) need to know which revision >> of llvm is installed. LDC currently asks llvm-config --src-root for the >> source

Hi Tom, DragonEgg depends on GCC's and LLVM's internal headers, auto-host.h is one of them. Try to add GCC and LLVM_CONFIG with your make command as described here http://dragonegg.llvm.org/ in section "Getting it". Best, - Dima. On 12/18/2012 10:24 PM, Tom Roeder wrote: > Hi, > > I'm trying to compile release 3.2 of DragonEgg (checked out from >

Hi Brian, Thanks for sharing your experience with dragonegg. I would like to use tilera-gcc as the compiler driver. native gcc would not be able to handle things like tilera specific intrinsics in the source code. I built dragonegg using GCC=/path/to/tilera-gcc48/bin/tile-gcc LLVM_CONFIG=/path/to/tilera-llvm/bin/tilegx-llvm-config make and also tried only emitting the IR