similar to: [LLVMdev] [llvm-c] LLVMInitializeNativeTarget not exported in shared library

Hi, when building llvm as a shared library LLVMInitializeNativeTarget and co. (located in llvm/Support/TargetSelect) will not get exported as symbol into the shared library, because they are static inline. Since they are functions defined in the C API no one else inside LLVM calls them, which results in them not being exported. This is, of course, no problem for C programs using the C API,

Hello All, I'm building an F# binding for LLVM and it seems to be working for the parts of Core and BitWriter that I've tested but I've hit problems with Target/ExecutionEngine. The following test code works with the initializeNativeTarget line commented out like so: <https://github.com/keithshep/llvm-fs/blob/b7050b841108dc703e58563a4cff8845603c950d/test/simpletest2.fs> ...

Hi David, I'm not certain, but to me the "LLVMSetTarget(module, "i686-apple-darwin11");" line looks suspicious. I'm not familiar with all the ins and outs of how target triples get handled, but it looks to me like that's requesting 32-bit code. I think that if you omit that line completely then the target will be inferred from the execution environment. My best

Hello, [Using LLVM r155315, according to `svn log | head`] I am experimenting with programatically building and jitting functions in a module, and I seem to be coming across a crash in some generated code. Using the llvm-c interface I build up the module which dumps like this: ; ModuleID = 'MyModule' target datalayout = "i686-apple-darwin11" target triple =

I would like to use the LLVM-C bindings to provide LLVM access with an OO-design in another language (D), e.g. map from the C API back up to a D API that closely resembles the original C++ API. Since I would like to have D (with its own exception system) to handle the IO, I need a new C API function (unless there is one and I haven't found it): LLVMBool

Okay after translating the headers to Delphi, i found more inconsistencies: > LLVMTypeRef LLVMFunctionType(LLVMTypeRef ReturnType, > LLVMTypeRef *ParamTypes, unsigned ParamCount, > LLVMBool IsVarArg); > In this case it is the other way around. 0 means False and anything else means true :/ (so it acts more like a

It seems that a client application needs to call InitializeNativeTarget or LLVMInitializeNativeTarget before doing any JITting. Unfortunately, LLVMInitializeNativeTarget is defined static inline and does not appear in the .a files; thus a client not written in C or C++ trying to JIT cannot link to the library and call LLVMInitializeNativeTarget that way. It can call a target-specific library

Kenneth Uildriks wrote: > It seems that a client application needs to call > InitializeNativeTarget or LLVMInitializeNativeTarget before doing any > JITting. Unfortunately, LLVMInitializeNativeTarget is defined static > inline and does not appear in the .a files; thus a client not written > in C or C++ trying to JIT cannot link to the library and call >

Hi, I stumbled across the following: > /* Builds a module from the bitcode in the specified memory buffer, > returning a > reference to the module via the OutModule parameter. Returns 0 on success. > */ > LLVMBool LLVMParseBitcode2(LLVMMemoryBufferRef MemBuf, > LLVMModuleRef *OutModule); However in most scenarios i know, a Bool is something like 0 = False !0 = True In short:

Of course, this is normal for C-APIs. But maybe change the name to LLVMResult to propagate the real use? I am not arguing about the results themself. They are standard. But the name is missguiding. As long as it's consistent i know that i have to write an extra record operator in Delphi to reflect this. 2016-09-12 11:11 GMT+02:00 David Chisnall <David.Chisnall at cl.cam.ac.uk>: > On

On Mar 13, 2013, at 6:40 AM, Moritz Maxeiner <moritzmaxeiner at googlemail.com> wrote: > Hi, > > If I write LLVM bindings for a language X, in which I obviously > need to at least use parts of the llvm-c headers (constants, enums, typedefs, function names and > signatures) do I need to include the LLVM copyright notice? > > Whereas llvm-c has multiple headers (e.g.

While writing bindings to LLVM for another language via the c api I noticed that LLVMAlignment and LLVMStackAlignment do not use 1<<x like all the others, but 31<<x and 7<x respectively (see below, or here: http://llvm.org/docs/doxygen/html/Core_8h_source.html#l00148). It's likely this is as it is intended, but it does look out-of-place enough that I thought it might be a

Hi, I have finished migrating all of the simplify-libcalls pass functionality into instcombine and functionattrs. Now I am ready to completely to remove what is left of the pass from the source tree. However, there are a few C API functions for creating and managing the pass: /** See llvm::PassManagerBuilder::DisableSimplifyLibCalls */ void

Dear all I am get the following problem when trying to compile app_meetme2 using mysql...it seems to want to use pgsql.....? anyone my Makefile looks like app_meetme2.o: app_meetme2.c #$(CC) -pipe $(CFLAGS) -c -o app_meetme2.o app_meetme2.c $(CC) -pipe -I/usr/local/include/mysql -L/usr/local/lib/mysql $(CFLAGS) -c -o app_meetme2.o app_meetme2.c app_meetme2.so: app_meetme2.o

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 LLVMCreateMemoryBufferWithContentsOfFile("code.bc", &buffer,

I've been struggling to get LLVM to work from .NET using the llvm-fs bindings for the past few weeks. I finally found an installation procedure that works and documented it here: http://fsharpnews.blogspot.com/2012/03/using-llvm-from-f-under-windows.html The good news is that I have that program compiling the Fibonacci function and executing it from F# all via LLVM. However, I still have a

Hello, a few days ago, I was trying to access the LLVM target registry via the LLVM-C interface. Unfortunately I can't seem to get some useful information out of it. Despite the fact that the following code is written in Pascal, can you please tell me if I have done something wrong here? // initialize all targets / target information LLVMInitializeAllTargets; LLVMInitializeAllTargetInfos;

On Sat, May 11, 2013 at 01:48:44PM +0200, Christian Budde wrote: > Hello, > > a few days ago, I was trying to access the LLVM target registry via the > LLVM-C interface. Unfortunately I can't seem to get some useful > information out of it. > > Despite the fact that the following code is written in Pascal, can you > please tell me if I have done something wrong here?

libswfdec/swfdec_as_strings.c | 7 + libswfdec/swfdec_asbroadcaster.c | 10 + libswfdec/swfdec_initialize.as | 1 libswfdec/swfdec_initialize.h | 8 - libswfdec/swfdec_net_stream.c | 10 + libswfdec/swfdec_player.c

Am 13.05.2013 16:16, schrieb Tom Stellard: > On Sat, May 11, 2013 at 01:48:44PM +0200, Christian Budde wrote: >> Hello, >> >> a few days ago, I was trying to access the LLVM target registry via the >> LLVM-C interface. Unfortunately I can't seem to get some useful >> information out of it. >> >> Despite the fact that the following code is written in