Re: LuaJIT vs require() on dumb C modules

[Mike Pall <mikelu-0805@...>]

Alexander Gladysh wrote:
> This works with plain Lua, but doesn't with LuaJIT. In LuaJIT that
> require() call returns true instead of my module's table. Am I missing
> something?

This is not LuaJIT's fault. You're simply not building the module
the right way.

According to the Makefile you provided, you're linking the module
_itself_ against whatever liblua is found in /opt/local/lib. This
makes a forward reference to this library (or a copy of it for a
static library). In your case this is probably the shared library
of an installed copy of Lua (and not LuaJIT).

So what happens when you load the module is that it binds to a
(possibly incompatible) copy of the Lua VM from /opt/local/lib
instead of the VM code already in memory (loaded by the executable
or contained in it). The different instances of the VM don't know
anything about each other and you'll encounter strange and hard to
diagnose problems.

[In particular: The module loader, table management and a few
other things use the address of pointers to static data as unique
values. But loading two copies of the same code forces different
addresses. Chaos ensues. The unexpected "true" return value from
loading a module is one of the known effects.]

Please read:

  http://lua-users.org/wiki/BuildingModules

and in particular the section:

  "Do Not Link Modules to the Lua Core Libraries"

C extension modules for Lua (on POSIX systems) have an _implicit_
dependence (via global symbols) on the Lua VM being part of the
executable or a shared library already loaded by the executable.
There MUST NOT be a forward dependence from a module to any
library containing any Lua VM whatsoever because then you cannot
load them from a different VM.

So, if you run "luajit", you are of course using a different VM
which is embedded in the executable. Except the poorly linked
modules have no clue about it.

[This is also precisely the reason why you should stay far, far
away from distributions (or modules delivered with bloated
"configure" scripts) that happily link all modules to whatever
liblua they find. You either end up with a dozen static copies in
memory or you cannot load the same modules into different (but
ABI-compatible) Lua VMs. Even a bugfix upgrade of Lua in such a
configuration can cause disaster when the new executable loads a
different shared library than any of the modules.]

The situation on Windows is different because all imported symbols
are qualified with the _name_ of a DLL (lua51.dll). As long as the
executable (lua.exe or luajit.exe) and all modules are linked with
the same import library (lua51.lib), you can never end up with two
different copies of the Lua VM in memory.

That said, LuaJIT 1.x is fully ABI-compatible with Lua 5.1.x and
you can use the same binary modules for both -- provided you build
them correctly.

--Mike