[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: How to find out which modules a binary Lua .so declares?
- From: Hisham <h@...>
- Date: Fri, 31 Aug 2018 13:29:09 +0200
So, here's an interesting problem: since multiple Lua modules can be
stored in a single .so file (looking at you, LuaSec!), one can't
really tell which Lua modules a rock contains by scanning the
This is currently causing `luarocks show` display incomplete data, and
has also caused bugs because other LR commands were naively assuming a
filesystem-to-modules correspondence. I do keep a list of module files
in rock_manifest, so those bugs are fixable.
But for luarocks.loader (a package searcher that resolves the right
version of a module based on LuaRocks metadata, so that if you require
a module A version 1 and it depends on module B version 3, it will
pick the right one even if you have multiple B's installed in your
system), the only way LuaRocks can resolve a require()d module is if
it knows which rock it belongs to. So missing this data means that
luarocks.loader is currently unable to resolve the LuaSec binary
I guess the only way to build complete module data will be to use nm
on Unix (and dumpbin on Windows I guess), at `luarocks build` time,
and search for "luaopen_*" symbols.
But then how to know if luaopen_foo_bar_bla means
require("foo_bar_bla"), or require("foo.bar.bla"), or
require("foo.bar_bla"), or require("foo_bar.bla")?
AFAICT, the right answer is "all of the above", so my current plan is
to "normalize" on one of those (say, dots) when storing the metadata
(i.e., "luaopen_foo_bar" means "foo.bar"), and have luarocks.loader
"normalize" the require() input when searching for .so files, in case
a non-"normalized" .lua filename cannot be found. Does that make