Re: LuaJIT 2 vs. C modules built for Lua

[Alexander Gladysh <agladysh@...>]

> 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:

>  Compatibility

>  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
>  replacement.

> 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
issue aside.)

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.

Indeed.

> 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
solution?

Thank you,
Alexander.