Library DLLs in 4.60+

Would it be possible to have Luacom, luasocket, et al. in a separate directory than the lua directory, and Mushclient set package.cpath to be %LUA_CPATH%;<MCInstallDir>\Lua\clibs?

I already have Lua for Windows installed, and have most if not all of these dlls. I don't want to run into DLL hell because versioning issues.

Well I don't really want to fiddle with the Lua package.cpath if I can help it, because there could be other side-effects.

Where do you have yours installed? Will they necessarily clash?

In any case, you can set the package.cpath in your Lua sandbox, which is a once-off change to affect all your scripts.

In any case I think we are already in DLL hell, frankly.

For one thing, some of the Lua libraries load against lua5.1.dll and others against lua51.dll. They have worked around that a bit, I believe, by releasing a "stub" DLL that redirects from one to the other (I forget which the "real" one is).

I found a while back that downloading some of the LuaBinaries files and trying to run them is indeed a special form of hell.

That is one of the reasons I am distributing my own copies, which are basically compiled from the original source, but at least linked against the "right" libraries to run with MUSHclient (eg. not against Cygwin).

I have LfW (Lua for Windows) installed to C:\Lua\5.1 . I manually set a system environment variable LUA_CPATH to C:\Lua\5.1\clibs\?.dll;

I would have to agree with Nick here, the sandbox code is almost certainly the best place to set the cpath.

lua5.1.dll is the real one.
lua51.dll is the stub (since we're not at version 51 yet)

Funny you should say that. I raised this issue in 2008 on the Lua mailing list and got told:



and:



Rightly or wrongly (personally I like the dot, since, as you say, it isn't Lua version 51), the issue hasn't really been resolved, and indeed people are prepared to argue both sides of the case.