Understanding lua extension dll building/loading i

问题:

I have a relatively complex lua environment and I'm trying to understand how the following would/could work. The starting setup includes the following two modules:

• Main application (no lua environment)
• DLL (statically linked to lua lib, including interpreter)

The dll is loaded into the main application and runs a lua console interpreter and a lua API accessible from the console.

Now, let's say I want to expand this setup to include another dll that would extend that lua API, luasql for example. The new dll needs to link against lua in order to build, and my understanding is that I cannot link against lua statically since there would now be two unshared copies of the lua code in process when I load the extension dll. However, even if I built the lua core lib as a dll and linked against it with the extension dll, that lua core dll would not be loaded at runtime by the main application or the primary dll. So my questions are:

1. What happens if I load that extension dll from the lua intepreter in the primary dll, considering that the lua core dll will not be loaded?
2. If I loaded the lua core dll at runtime, how would that conflict with the statically linked lua lib?
3. Would both scenarios (linking statically in extension dll and dynamically linking/loading the lua dll) result in having two copies of the lua core code in process?
4. In that event, what would happen if I tried to call an API function from the primary dll's lua environment/interpreter that was built/loaded in the extension dll?
5. OR does lua have some kind of special mechanism for loading native dlls that provide new C API functions that allows it to bypass normal linking rules?

Hopefully I have provided enough details to make the questions specific, if not I will be happy to refine the scenario/questions further.

Edit: I have looked at Bundling additional Lua libraries for embedded and statically linked Lua runtime and I believe it may be helpful in providing a solution ultimately but I'd like to understand it at the linker level.

回答1:

You can't have the situation when you load one interpreter (let's say it's linked statically) and load a module X that is linked against a dll with a Lua interpreter, which loads another copy of the interpreter. This is likely to cause an application crash. You need to make the loaded dll to use the interpreter that is already loaded, either by linking against that dll with the interpreter or by using a proxy dll (see below).

You have two main options: (1) make dllA that is loaded by the main application that in turn depends on Lua dll; you can then link all other lua modules against Lua dll without any issues; or (2) include Lua dll into dllA, but keep Lua methods exposed so that lua modules can be linked against that dllA.

I think the first option is much simpler and likely not to require any changes to the Lua modules (as long as you can keep the name of the Lua dll the same as the one that the modules are compiled against).

Another option I should mention is that you can still use Lua modules compiled against a Lua DLL even with applications that have the Lua interpreter statically compiled. You need to use a proxy DLL; see this maillist thread for the solution and related discussion.

回答2:

The answer boils down to this:

1. Don't try to load any Lua extensions from a dll linked against a different Lua-core. Doing so will cause utter chaos.
2. As long as any Lua extension loaded resolves all its dependencies to the proper Lua core, it does not matter (aside from bloat) how many Lua cores you use.

Keep in mind that windows always resolves symbols according their name and their providing dll.