Linking DLL modules

Questions about the LÖVE API, installing LÖVE and other support related questions go here.
Forum rules
Before you make a thread asking for help, read this.
Post Reply
User avatar
criptych
Prole
Posts: 9
Joined: Fri Dec 24, 2010 8:18 pm

Linking DLL modules

Post by 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.)
User avatar
RedHot
Citizen
Posts: 87
Joined: Mon May 27, 2013 2:43 pm
Location: Poland

Re: Linking DLL modules

Post by 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.
User avatar
criptych
Prole
Posts: 9
Joined: Fri Dec 24, 2010 8:18 pm

Re: Linking DLL modules

Post by 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.
User avatar
Boolsheet
Inner party member
Posts: 780
Joined: Wed Dec 29, 2010 4:57 am
Location: Switzerland

Re: Linking DLL modules

Post by 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. :P

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.
Shallow indentations.
User avatar
slime
Solid Snayke
Posts: 3131
Joined: Mon Aug 23, 2010 6:45 am
Location: Nova Scotia, Canada
Contact:

Re: Linking DLL modules

Post by slime »

Boolsheet wrote: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.)
User avatar
criptych
Prole
Posts: 9
Joined: Fri Dec 24, 2010 8:18 pm

Re: Linking DLL modules

Post by criptych »

Boolsheet wrote: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. :P
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.
Post Reply

Who is online

Users browsing this forum: Ahrefs [Bot], Google [Bot] and 37 guests