了解lua扩展dll构建/加载静态链接嵌入式lua环境 [英] Understanding lua extension dll building/loading in statically linked embedded lua environment

问题描述

我有一个比较复杂的lua环境，我正在努力了解以下内容将如何运作。启动设置包括以下两个模块：

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:

• 主应用程序（无lua环境）


• DLL （静态链接到lua lib，包括口译员）

将dll加载到主应用程序中，并运行一个lua控制台解释器和一个lua API可从控制台访问。

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

现在，我想展开这个设置以包含另外一个扩展lua API，luasql的dll。新的DLL需要链接到lua才能构建，我的理解是，我无法静态链接lua，因为当加载扩展名dll时，现在将有两个未共享的lua代码副本。然而，即使我将lua core lib作为一个dll并与扩展名dll链接起来，那么lua core dll将不会在运行时被主应用程序或主要DLL加载。所以我的问题是：

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. 如果我从主要DLL中的lua intepreter加载该扩展名，那么会考虑到lua core dll不会加载？


2. 如果我在运行时加载了lua核心DLL，那么与静态链接的lua lib会如何冲突？


3. 方案（在扩展DLL中静态链接并动态链接/加载lua dll）导致在进程中有两个lua核心代码副本？


4. 在这种情况下，如果我尝试从主DLL的lua环境/解释器调用一个API函数，该环境/解释器是在扩展dll中构建/加载的。


5. 或者，lua有一些特殊的机制来加载本地的dll，提供新的C API函数允许它绕过正常的链接规则？

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.

编辑：我看过将用于嵌入式和静态链接的Lua运行时的其他Lua库捆绑在一起，我相信最终可能有助于提供解决方案，但我想在链接器级别了解它。 >

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.

推荐答案

当您加载一个解释器时，您不能有这种情况（假设它是静态链接的），并加载与一个与Lua解释器的DLL，它加载了另一个口译副本。这可能导致应用程序崩溃。您需要使加载的dll使用已加载的解释器，无论是通过将该DLL与解释器相链接还是使用代理dll（见下文）。

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).

你有两个主要选择：（1）使dllA由主应用程序加载，而依赖于Lua dll;然后你可以链接所有其他lua模块对Lua dll没有任何问题;或者（2）将Lua dll包含到dllA中，但是保持Lua方法暴露，以便lua模块可以链接到该dllA。

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.

我认为第一个选项要简单得多可能不需要对Lua模块进行任何更改（只要您可以保持Lua dll的名称与模块编译的相同）。

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).

另一个选择我应该提到的是，您仍然可以使用Lua DLL编译的Lua模块，即使是具有Lua解释器静态编译的应用程序。您需要使用代理DLL ;有关解决方案和相关讨论，请参阅此maillist线程。

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.

这篇关于了解lua扩展dll构建/加载静态链接嵌入式lua环境的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！