lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

I read a discussion around 2006 about the way Lua loads libraries on Windows, and why didn't ll_load call LoadLibraryEx with LOAD_WITH_ALTERED_SEARCH_PATH.

I'm proposing that, again, but for a different reason.
One of the nice things about LuaRocks is that I can deploy modules without messing with other stuff. Each module is, in a way, isolated. Since Lua's require ends up loading libraries using a full path, there are no ambiguities on where that module is coming from.

But... the other libraries our module references can't be found.
For instance, I'm building a rock that installs precompiled versions of lrexlib. It installs rex_pcre.dll where luarocks specified, and pcre.dll in the same directory. However, I can't require rex_pcre, because rex_pcre.dll depends on pcre.dll. This dependency isn't handled by a plain LoadLibrary. Windows performs a lookup using the usual rules. For it to work, with a vanilla Lua installation, I have to copy pcre.dll to somewhere in my PATH, or worse, to system32.

If I change ll_load to call

then, when it loads a library, it resolves its references first using the path specified in the call to LoadLibraryEx.

But... (yes, another), for that to work, path has to be sanitized. While this works fine using LoadLibrary: package.loadlib([[C:\LuaRocks\rocks/rex_pcre/sscm-1/lib/rex_pcre.dll]], "luaopen_rex_pcre")

it doesn not work with LoadLibraryEx. Forward slashes needs to be changed to back slashes. package.loadlib([[C:\LuaRocks\rocks\rex_pcre\sscm-1\lib\rex_pcre.dll]], "luaopen_rex_pcre")

Could some scheme like this  be taken into consideration for Lua 5.2 ??

Ignacio Burgueño