Weirdness loading a module.

Posted by WillFa on Mon 17 May 2010 07:53 PM — 10 posts, 45,424 views.

WillFa USA Mon 17 May 2010 07:53 PM #0

After installing Lua for Windows, one of the modules fails to load in Mushclient with "The specified procedure was not found." This only happens with Mushclient.

1. Download and install Lua for Windows from http://code.google.com/p/luaforwindows/
2. Set system environment variable LUA_CPATH=C:\Lua\5.1\clibs\?.dll; (or where you installed it + \clibs\?.dll;)
3. Open Lua (Command Line) - start/programs/lua/...
4. require "LuaXML"
5. print(package.loaded.LuaXML) -> true
6. print (xml) -> bunch o functions... the module name is hard coded in the module source
7. print(xml.load("C:/path/to/my/world.mcl") -> data, not errors

Okay, it works.

(Re)Start MuschClient, open a new dummy world (ip 0.0.0.0), comment out the sandbox, check allow dlls, set a script char, (...auto say, script char, send to execute)

require "LuaXML"

*Boom* The specified function was not found.

(I tend to use MC instead of Lua Command Line for debugging code. It's quick, the command history and such makes using it a nice interactive prompt. Using AddXML from MC isn't really the point, MC not loading modules that other Lua interpreters (Lua.exe, Scite, etc) can use is.)

David Haley USA Mon 17 May 2010 08:39 PM #1

I'm assuming that you restarted after changing the system-wide environment variable? In other words, are you sure that MUSHclient is getting the correct Lua path?

Nick Gammon Australia Forum Administrator Mon 17 May 2010 09:08 PM #2

I know what the problem is, I'm not sure the best way to fix it. If you look at the file LuaXML_lib.dll in the dependency walker you see this:

Now the DLL is trying to load against lua51.dll but MUSHclient ships with lua5.1.dll (note the extra dot).

I've tried a few workarounds, but what is happening for reasons I don't understand is, if you get past the error (for example, by recompiling the LuaXML_lib.c file and changing the Makefile to use -llua5.1 rather than -llua51 then when you require "luaxml" it simply hangs, but not in a CPU loop.

It's as if it is waiting for standard input or something.

I don't know what to suggest, maybe this will give someone else a clue. I note that on this page http://lua-users.org/wiki/LuaXml there is a Lua-only version of an XML parser written by Roberto Ierusalimschy.

WillFa USA Mon 17 May 2010 09:33 PM #3

David Haley said:

I'm assuming that you restarted after changing the system-wide environment variable? In other words, are you sure that MUSHclient is getting the correct Lua path?

Yup. print(package.cpath) is correct.

@Nick, There's a copy of lua51.dll in the clibs directory as well, the same dir as luaxml_lib.dll... I'd think it would find it... I'll check out Roberto's xml module tho.

Nick Gammon Australia Forum Administrator Mon 17 May 2010 10:07 PM #4

Ah yes, but using multiple Lua DLLs is likely to lead to crashes, as one DLL might allocate memory from one lot of memory space, and the other one might try to free it.

This issue has come up on the Lua mailing list, there was some inconsistency about whether to name the DLL lua5.1.dll or lua51.dll. Personally I think lua5.1.dll is better because it is Lua version 5.1, not Lua version 51.

I believe there was a workaround where they had one DLL which was the "real" lua DLL, and the other one simply referenced the other one (eg. something like lua51.dll -> lua.5.1.dll). That way you didn't really have two different dlls, and some libraries linked against one, and some against the other. Really, it is a big mess.

WillFa USA Mon 17 May 2010 10:39 PM #5


C:\Lua\5.1\clibs>dir lua5*.dll
 Volume in drive C has no label.
 Volume Serial Number is 3CC6-E5D5

 Directory of C:\Lua\5.1\clibs

03/24/2009  09:46 PM           167,936 lua5.1.dll
01/26/2009  11:08 AM           126,976 lua51-lanes.dll
08/28/2008  02:04 PM            11,264 lua51.dll
               3 File(s)        306,176 bytes
               0 Dir(s)  88,488,095,744 bytes free

Given the size difference, I'd say that's what they did.

I'll see if adding clibs to the system path helps.

WillFa USA Tue 18 May 2010 06:46 PM #6

Adding clibs to the system path didn't help.

I think it's really weird that it works everywhere but MC. lua.exe, scite, Mudlet (another client with lua embedded in it)

David Haley USA Tue 18 May 2010 06:48 PM #7

There's still the issue of multiple Lua libs; I don't remember if MUSHclient links statically or dynamically with Lua, but if it does the "wrong" thing (where "wrong" in this context means not MC's fault but incompatible with the other libs) it can cause breakage.

The other clients might simply be linking differently.

Twisol USA Tue 18 May 2010 07:47 PM #8

David Haley said:
I don't remember if MUSHclient links statically or dynamically with Lua

Dynamically.

Nick Gammon Australia Forum Administrator Tue 18 May 2010 08:56 PM #9

Quite right, Twisol. I initially linked statically but that caused crashes if you interfaced with other DLLs (eg. LuaSocket) because they were allocating Lua objects in different address spaces.

The group that did the Windows precompiled ports must have decided at some stage to change the name of the DLL, I am pretty sure when I initially did it, I used a name that worked with things I had downloaded (eg, LuaSocket, LuaCOM, LuaSQL) otherwise there wouldn't have been much point would there?

Installing that intermediate DLL (lua51.dll) may help to live in a mixed environment. This still doesn't explain why the XML parser seemed to hang for me when I recompiled it. And unfortunately as it was under Windows I had little success using gdb to work out what it was doing.

The versions of LuaSocket etc. on this site (in the downloads area) have been - in some cases at least - recompiled by me to make them compatible with the DLL that ships with MUSHclient.