[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: LuaJIT 2 vs. C modules built for Lua
- From: Alexander Gladysh <agladysh@...>
- Date: Tue, 10 Nov 2009 11:36:21 +0300
> Alexander Gladysh wrote:
>> This looks like a silly question, and I feel that it should be
>> documented somewhere, but anyway:
>> Can LJ2 be used with C modules, linked with Lua (on Linux / OS X platforms)?
> The very first section in http://luajit.org/luajit.html says:
> LuaJIT implements the full set of language features defined by
> Lua 5.1. The virtual machine (VM) is API- and ABI-compatible to
> the standard Lua interpreter and can be deployed as a drop-in
> The 'B' in "ABI-compatible" means binary module compatibility.
Sorry, I've missed that one :-)
>> My intuition says "no". Then I feel that LJ2 should ignore LUA_CPATH
>> and have its own environment variable.
> Alas, your intuition is wrong.
That happens often. :-)
> It's deliberately using the same module paths.
Good news. So, no need to recompile any of my Lua modules? (32/64-bit
I feel that this question may be worth adding to the LuaJIT FAQ. :-)
>> Looks like practice says "yes" — what I've tried worked. But this is
>> strange. What am I missing? What are the consequences?
>> What if modules are accidentally compiled as 64-bit code?
> This is not specific to LuaJIT.
> The 32/64 bit issues are going to
> hurt you with a mixed 32 bit/64 bit Lua installation, too:
> lua64: error loading module 'test' from file './test.so':
> ./test.so: wrong ELF class: ELFCLASS32
I see that this is not specific to LuaJIT, but I still have a question:
Any standard way to workaround this issue on 64-bit Linux? I need to
keep both Lua and LuaJIT working.
I think that LuaRocks compiles Lua modules into 64-bits.
It seems that I have to keep *manually* two separate module trees, and
to change LUA_CPATH before I launch Lua or LuaJIT. Is there a better