search

mikehend / luainterface

Automatically exported from code.google.com/p/luainterface
0 stars 0 forks source link

Latest lfw modules don't work with latest Luainterface #13

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
1. Install latest lfw (Lua For Windows).
2. Use LuaRunner from latest LuaInterface.
3. run it with a script containing:
package.cpath = package.cpath .. ";" .. "C:\\Program Files\\Lua\\5.1
\\clibs" -- change to wherever you installed the modules.
require("bit") -- or "luacom" or "lfs"

What is the expected output? What do you see instead?
I get:
"error loading module 'bit' from file 'C:\004\bit.dll':
        %1 is not a valid Win32 application."
Instead of returning a table for the module.

What version of the product are you using? On what operating system?
Tried both official Luainterface 2.0.3 or latest code from here.
With ver. 1.5.3 the modules are loaded fine.

Please provide any additional information below.
I really like the new debugger support and use it extensivly, But it's a 
real pitty if I can't use all the ready made libraries.

Original issue reported on code.google.com by aban...@gmail.com on 19 Jan 2010 at 4:59

GoogleCodeExporter commented 9 years ago 
I've managed to solve my issue with Luainterface and lua modules compatibility. 
The 
problem was indeed with mismatching runtime libraries (Thanks Steve), this time 
it 
was the Debug C Runtime vs. release. The setup which finally worked was a 
release 
version of Luainterface, compiled using a debug version of Lua51 (as 
reference), 
while the Lua51 linked the Multithreaded DLL library (and not Multithreaded 
Debug 
DLL). 
Weird setup, but it worked and required just installing the the latest vcredist 
from 
Microsoft (which is the release C Runtime), as mentioned in the Luainterface 
google 
site.
Why using a release version of the Lua51 doesn't work is still a mystery to 
me...

Original comment by aban...@gmail.com on 1 Feb 2010 at 5:39

GoogleCodeExporter commented 9 years ago 
I'm a little late to this, but I ran into this issue too.  I found out that the 
Lua51 release build defaulted to using the __stdcall instead of the __cdecl 
calling convention. Changing it fixed the issue for me (oh and I believe 
LUA_BUILD_AS_DLL wasn't listed as one of the preprocessor definitions).  
Hopefully that helps anyone else who might run into this.

Original comment by carebear...@gmail.com on 20 Jun 2010 at 4:24