使用静态构造函数链接 dll 时如何解析未解析的外部符号？答案

【问题标题】：How to resolve unresolved external symbol when linking against dll with static constructors?使用静态构造函数链接 dll 时如何解析未解析的外部符号？
【发布时间】：2019-08-15 03:43:30
【问题描述】：

我正在用一些实用程序、工具等在 D 中构建一个 dll。我可以成功编译一个基本的 dll 并测试程序以在 Visual D 中使用它而没有任何问题。我熟悉创建和使用 dll 的过程。特别是针对它们的静态链接。但是如果 dll 中的模块有一个静态 this()，或者导入一个带有静态 this() 的模块，则 dll 将编译，但您构建的任何使用它的程序都会失败，并且 foo.bar.__ModuleInfo 未解析。

错误 LNK2001：无法解析的外部符号“dtoolbox.dtoolboxdllmain.__ModuleInfo”(__D8dtoolbox15dtoolboxdllmain12__ModuleInfoZ)

在这种情况下，我的 dllmain 模块 dtoolbox.dtoolboxdllmain 导入 core.runtime ，它有一个静态的 this() 所以我得到这个错误。我该如何解决这个问题？什么是静态模块构造函数导致这种情况？只要没有静态构造函数，一切正常。

[edit] 导入 core.runtime 不是问题，是模块自己的静态 this()，而不是 core.runtime 的静态 this()。

【问题讨论】：

源导入文件是什么样的？您是在导入原始的 .d 文件还是一个去掉了函数体的文件（又名 .di 文件）？
亚当，你问的回答。出于某种原因，我正在导入原始的 .d 文件，在本例中是带有 dllmain 的文件。我什至不需要导入它，因为它没有导出任何可用的功能。我从测试项目中删除了导入，一切正常。我做了一些测试，发现你不能直接使用静态 this() 导入模块，我认为这就是 .di 的用途？
是的，di 文件（它实际上只是一个 D 文件；编译器对它们的处理方式完全相同，但按照惯例，我们将其命名为 .di，当主体被剥离时）可以让您隐藏这些类型来自调用者的内部详细信息。您可以取出模块 ctor/dtors（在 dll 内部处理）、大多数函数体、大多数私有成员 - 隐藏除最低要求接口之外的任何内容。顺便说一句，您可能想写这篇文章作为对自己的回答，以供未来的读者参考。

标签： dll linker d unresolved-external

【解决方案1】：

解决方案是避免将带有 dll 的 static this() && static ~this() 的模块导入使用 dll 的程序的模块中。（在这种情况下，dllmain 模块正在被导入，完全没有理由，我的错误）并不是说 dll 不能拥有它们，但它们只需要在编译 dll 时存在于某个文件中。我发现将它们写在与您的 dllmain 相同的模块中很方便，因为使用 dll 的程序永远不需要引用/导入该文件。

【讨论】：