search for: libmylib

...is Crystal. I have some questions about llvm-gcc. Could you please give me some advice? Thanks in advance. Problem description: Env: llvm-gcc (GCC) 4.2.1 gcc (GCC) 4.1.2 OS:fedora7 I tried to compile a C programme test.c with llvm-gcc by task: [root at localhost mylib]# llvm-gcc -emit-llvm test.c -Llibmylib.a -c -o test.bc [root at localhost mylib]# lli test.bc after running the command "lli test.bc",print the error info as follows: ERROR: Program used external function 'gt' which could not be resolved! lli[0x85c245f] /lib/libc.so.6(abort+0x101)[0x6988b1] lli(_ZN4llvm3JIT25getPointe...

...source code compilation process builds a static library (.a archive file), I need a means to link the `.a' file statically into the application. So if the original statement was: gfortran file.o -L somedir -lmylib -o file then my modified compilation process would have to deal with file.o and libmylib.a to generate the binary `file'. Now, all files essentially contain bitcode (file.o and object files inside libmylib.a). So the pseudo-code would look like: -- QUOTE -- For all input files passed to compiler: If extension is .o: Use llc to generate .s file Add this filenam...

...process builds a static library (.a archive file), I > need a means to link the `.a' file statically into the application. So if > the original statement was: > gfortran file.o -L somedir -lmylib -o file > then my modified compilation process would have to deal with file.o and > libmylib.a to generate the binary `file'. Now, all files essentially contain > bitcode (file.o and object files inside libmylib.a). So the pseudo-code > would look like: > -- QUOTE -- > For all input files passed to compiler: >     If extension is .o: >         Use llc to generate .s f...

...ry (.a archive > file), I > > need a means to link the `.a' file statically into the application. So if > > the original statement was: > > gfortran file.o -L somedir -lmylib -o file > > then my modified compilation process would have to deal with file.o and > > libmylib.a to generate the binary `file'. Now, all files essentially > contain > > bitcode (file.o and object files inside libmylib.a). So the pseudo-code > > would look like: > > -- QUOTE -- > > For all input files passed to compiler: > > If extension is .o: > &g...

On Thu, Jun 18, 2009 at 3:57 PM, Jules Jacobs<julesjacobs at gmail.com> wrote: > How can I call C++ libraries (LLVM & Qt for example) from a language that's > implemented on top of LLVM? You can call them the same way a C++ file compiled with llvm-g++ would call them. Essentially, it's complicated enough that you probably don't want to do it for any interface of

Hi, How can I call C++ libraries (LLVM & Qt for example) from a language that's implemented on top of LLVM? Thanks, Jules -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090619/4621508b/attachment.html>

Thanks for responding. Sorry for the delay in my reply, but I was dealing with hurricane Sandy. Anyway.... My software build produces libmylib.so. The JIT'd function only calls external C functions in libmylib.so and not other JIT'd functions. The C functions are simple thunks to call constructors. For example, given: class BinaryNode : public Node { public: BinaryNode( Node *left, Node *right ); // ... }; there exis...

Sorry, at what step do you need archive? llc emits binary, it does not perform any linking, thus it does not need anything except the input bytecode file. Then during linking you can link whatever archives of binaries you want. 2011/9/13 Ashay Rane <ashay.rane at tacc.utexas.edu>: > Thats correct. But using llc becomes a problem when I have archives (.a > files). I could, in theory,

...J. Lucas Sent: Tuesday, November 06, 2012 7:44 AM To: llvmdev at cs.uiuc.edu List Subject: Re: [LLVMdev] Using LLVM to serialize object state -- and performance Thanks for responding. Sorry for the delay in my reply, but I was dealing with hurricane Sandy. Anyway.... My software build produces libmylib.so. The JIT'd function only calls external C functions in libmylib.so and not other JIT'd functions. The C functions are simple thunks to call constructors. For example, given: class BinaryNode : public Node { public: BinaryNode( Node *left, Node *right ); // ... }; there exis...

I'm not sure I have a clear picture of what you're JIT'ing. If any of the JIT'ed functions call other JIT'ed functions, it may be difficult to find all the dependencies of a functions and recreate them correctly on a subsequent load. Even if the JIT'ed functions only call non-JIT'ed functions, I think you'd need some confidence that the address of the called

Thats correct. But using llc becomes a problem when I have archives (.a files). I could, in theory, extract its contents to a tempdir and then use llc and link but just wondering if there is a more elegant solution. Ashay On Mon, Sep 12, 2011 at 3:00 PM, Dmitry N. Mikushin <maemarcus at gmail.com>wrote: > Ashay, > > If I understand correctly, in hw.o you would have llvm

On Sat, Jun 20, 2009 at 07:17:50AM -0700, pablogreen wrote: > Normally in C++ I do this: > g++ -fPIC -c mylib.c > g++ -shared -o libmylib.so mylib.o Try compiling with GCC in C mode because C++ mangles the names (e.g. to support overloading). -- Felipe.

...b.c: #include <stdio.h> void printString(char *str) { printf("%s", str); } mylib.h: #ifndef MY_LIB_HEADER #define MY_LIB_HEADER void printString(char* X); #endif /////////////////////////////////////// Normally in C++ I do this: g++ -fPIC -c mylib.c g++ -shared -o libmylib.so mylib.o (and after that : g++ -Wall -g -o prog.exe prog.c -I./ -lmylib -L./ LD_LIBRARY_PATH=/home/mylinux/Desktop/test ./prog.exe) My program I compile like this: $ llvm-as -f prog.ll $ llc -march=x86-64 prog.bc -f but I have error after: $ g++ -o prog prog.s -I./ -L./ -lmylib /tmp/ccLAh0m...

I have a legacy C++ application that constructs a tree of C++ objects (an iterator tree to implement a query language). I am trying to use LLVM to "serialize" the state of this tree to disk for later loading and execution (or "compile" it to disk, if you prefer). Each of the C++ iterator objects now has a codegen() member function that adds to the LLVM code of an