lua-users home
lua-l archive

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

steve donovan  writes:
> On Sun, Aug 24, 2008 at 8:50 PM, RJP Computing wrote:
> > ...can I get some feedback on the original issue about adding
> > the 'clib' to the default Lua Binaries....
> ...Adding 'clib' would be consistent with existing package.path
> where there is a 'lua' directory for pure Lua libs.

In comparison...

- In LuaRocks[1], the source (.lua) libs are found in directories named "lua",
and the binary (.so/.dll) libs are found in directories named "lib".

- In luaconf.h of Lua 5.1.4 (and LuaBinaries), the source libs are found in an
absolute path containing the name "lua" (under Windows) or containing the name
"share/lua" (under non-Windows).  The binary libs are found in the absolute path
of the Lua executable (under Windows) or containing the name "lib/lua" (under

So the current convention (not to say it's ideal) seems mostly for LUA_PATH and
LUA_CPATH to correspond to "lua" and "lib" directories respectively.  There is
no "clib" as might suggest "clib" contains binary libs and "lib" contains non-C
(Lua only) libs.

But I agree that the fact that Windows binary libs are searched for in the same
directory as the Lua interpreter does seem inconsistent and messy.

There is a complication though that might explain it: say lua.exe loads a Lua
module named myluamodule.dll (via LUA_CPATH) that in turn loads a regular
(non-Lua) DLL named zlib1.dll (via PATH and the Windows DLL search order [2]). 
Windows ignores LUA_CPATH when loading zlib1.dll.  So, typically, you would
place zlib1.dll in either a system directory (undesirable) or the same directory
as lua.exe.  The latter leads to the same problem of DLLs littering your lua.exe
directory.  One solution (which LfW does but which I don't think LuaRocks
supports) is to modify PATH to correspond to LUA_CPATH.  There is alternately a
SetDllDirectory[3], but that is not available in older versions of Windows.  So,
if you add "!\clib" to LUA_PATH, it may be best to also patch Lua to append that
directory to PATH via _putenv[4] so as to avoid (as LfW currently does) globally
modifying the PATH environment variable.  You might not want to go so far as to
dynamically update PATH whenever package.cpath is dynamically changed though.