Linking DLL modules

[criptych]

So I've been writing this module in C++ to use with LÖVE. I've gotten it working with the command-line Lua interpreter, but now I want to test it in LÖVE proper, and I don't know what to link it against. Using "love/lib/x86/.../lua51.lib" gives me a "lua51.dll not found" error at run time, and using "platform/msvc2010/lib/lua.lib" generates a batch of "undefined reference to <various Lua symbols>" errors at link time.

But what I really want is to link my module so that it uses LÖVE's internal copy of the Lua library, to avoid the dreaded "multiple VMs" error. What's the best way to do that? Should I just rebuild LÖVE from source, use an external Lua library, or what?

(N.b. This is in Windows, of course. All seems to work fine under Linux. Go figure.)

[RedHot]

You just need to get straight what kind of linking you wish to use. If you get an error stating that a certain DLL was not found, just build everything as static.

[criptych]

But linking statically with Lua from multiple modules is known to cause issues. As stated, if possible I want to link dynamically against the same Lua instance as LÖVE itself, which AFAICT on Windows is statically linked into the executable. If that's the case, I either need to link against the executable (does it even export Lua symbols?) or rebuild it using an external dynamic library. The former is preferable, since the latter then requires a "non-standard" build of LÖVE. In short, I want to be able to distribute the module as-is and have it "just work" in any LÖVE installation.

[Boolsheet]

Yes, the official LÖVE 0.8.0 builds for Windows have Lua statically linked (for VC++ runtime library IO and distribution reasons) and they do not export the symbols. Yes, the clean solution is to rebuild LÖVE and linking with a dynamic Lua instead (in that case, you also want the dynamic VC++ runtime library). It is possible to just drop a second Lua library into the DLL search path and use that. It seems to work (with simple modules), but it feels really dirty. And if there's an issue, everything dies in a fire.

The official OS X build also has issues in this regard. I think the Lua in it was built with some option disabled and it can't load libraries.

The only place this works out-of-the box is on the Linux platform. Point Linux, for having the tendency to make all libraries dynamic ones. It's very likely this is getting a lot better in 0.9.0 though.

[slime]

The official OS X build also has issues in this regard. I think the Lua in it was built with some option disabled and it can't load libraries.

The only place this works out-of-the box is on the Linux platform. Point Linux, for having the tendency to make all libraries dynamic ones. It's very likely this is getting a lot better in 0.9.0 though.

For OS X this is fixed in 0.9.0, or you can download my updated OS X build of 0.8.0 (which uses a fixed version of Lua as well as OpenAL Soft instead of Apple's OpenAL.)

[criptych]

Yes, official LÖVE 0.8.0 builds for Windows have Lua statically linked (for VC++ runtime library IO and distribution reasons) and they do not export the symbols. Yes, the clean solution is to rebuild LÖVE and linking with a dynamic Lua instead (in that case, you also want the dynamic VC++ runtime library). It is possible to just drop a second Lua library into the DLL search path and use that. It seems to work (with simple modules), but it feels really dirty. And if there's an issue, everything dies in a fire.

Thanks, this is exactly the information I was looking for. For my purposes, if I'm going to rebuild LÖVE anyway, I might just as well build the module into it too.