tags:

views:

180

answers:

2

I'm looking at incorporating Lua into a C++ project, and am a bit confused by the presence of the two binaries (lua51.dll and lua5.1.dll) in the distribution from Luabinaries.

According to the docs...

In Windows your library or application must be linked with a stub library. A stub library is a library with only the function declarations that will bind your DLL with the Lua DLL.

Why? I've never needed stub DLLs before when linking with third-party DLLs?

+3  A: 

A stub library is a .lib file, not a DLL. It contains function declarations for all the exported functions in the DLL, which just forward the call into the DLL itself. So if you build an application that you want to link with lua51.dll, you tell the linker to link with lua51.lib, and all calls to exported functions will be forwarded to the DLL. If you didn't do this, you would get a lot of "unresolved external symbol" errors when linking.

This is only needed when statically linking with a DLL (so that it is loaded automatically when the application is run). It is not needed when loading the DLL dynamically with LoadLibrary.

Regarding why they have two different DLLs, The manual says this:

The LuaBinaries DLL packages have a dll proxy called "lua51.dll". It can be used to replace other "lua51.dll" released by other distributions. It will simply forward calls to the "lua5.1.dll". There is no compiled source code involved in the forwarding.

Basically, some existing applications link with lua5.1.dll while others link with lua51.dll and they want to support them both. In any case this is not related to the stub libraries.

interjay
Thanks, I simply missed the part of the docs you quoted , and got myself confused between the 'forwarding' done by lua51.dll (to lua5.1.dll) with the dynamic link 'forwarding' done by linking in the static lib file. As an aside, surely you could just copy and rename "lua51.dll" to "lua5.1.dll" for systems that wanted the differently named DLL - avoiding having two confusingly named .DLL files....???
Roddy
@Roddy: Some applications may need both DLLs (because they use libraries which link with different DLLs). In that case it's better to use forwarding than copies: It will save memory and may prevent hard-to-find bugs due to having two copies of the same library interoperating with each other.
interjay
A: 

I believe it's to do with __declspec(import) and __declspec(export) vs GetProcAddress. However, I don't actually know for sure.

DeadMG