Re: How to find out which modules a binary Lua .so declares?

[Marc Balmer <marc@...>]

> Am 31.08.2018 um 13:29 schrieb Hisham <h@hisham.hm>:
> 
> 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
> filesystem.
> 
> 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
> modules.
> 
> 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
> sense?

On Linux, you could use dl_iterate_phdr.  But note that this is not portable.

- Marc