[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: [ANN] llvm-lua 1.0
- From: "Robert G. Jakabosky" <bobby@...>
- Date: Sat, 6 Jun 2009 21:04:58 -0700
On Friday 05, Alexander Gladysh wrote:
> We use Lua built as .so. Is this fine with llvm-lua?
I just checked in a change to the Makefiles that will build a liblua-llvm.so
file. LLVM must be compiled with PIC support (configure
option "--enable-pic" which is turned on by default now, but was always). I
had to re-compile LLVM to get PIC support on my system.
I don't know if LLVM supports being compiled as shared libraries. The default
seems to be to only build static libs. This means that the host application
needs to be statically linked to some of the LLVM libs, this adds about
9Mbytes (about 90Mbytes if you compiled LLVM with debug info) to the binary
Here is how to compile llvm-lua/etc/min.c with JIT support:
gcc -o etc/min.o -c etc/min.c
g++ -o etc/min etc/min.o -llua-llvm `llvm-config --ldflags --libs core jit
native linker` -rdynamic -Wl,-E -lm -ldl
Make sure to not leave out "-rdynamic -Wl,-E" that is required by the JIT to
link the JITed lua functions to the functions in the Lua core.
> >> > Right now that one instance of LLVMCompiler is shared by all
> >> > lua_States, I might move the global variable to a member variable of
> >> > 'lua_State' . A lock on that shared instance might still be the best
> >> > option. I will look into this for the next release.
> Perhaps it is better to be left configurable -- there are probably
> uses for either of options.
Using a lock would require linking llvm-lua with pthreads or some other thread
library. I might add the lock method as a configurable option later. It
would also be good to support the global one instance of LLVMCompiler for
people that need to create lots of lua_State's but only use them all in one
Robert G. Jakabosky