将 D 项目编译为库 - 依赖项会发生什么？

Question

好的，这是我的问题：

我有一个正在运行的 DUB 项目，它可以生成一个应用程序。我决定在我的dub.json 文件中还需要一个“库”配置：

"configurations": [
    {
        "name": "application",
        "targetType": "executable"
    },
    {
        "name": "library",
        "targetType": "library",
    }
],

所以，现在当我使用dub build --config=library 构建项目时，它会在同一目录中生成一个libXXXX.a 文件。

到目前为止，一切都很好。

我尝试使用这个库（实际上是一个来自测试 C 应用程序的标记为 extern "C" 的小测试函数）。

所以，我使用 gcc -c ctest.c 编译我的 C 应用程序，然后像 dmd libMYLIBRARY.a ctest.o 一样将它们链接在一起。

现在，问题来了：

在最后一步中，链接器抱怨缺少许多符号 - 所有符号都来自 外部依赖项（2 个目标文件和几个 .a 库）在将项目构建为应用程序时进行链接。

那么，问题是……我该如何解决这个问题？

我的意思是...我应该将我的测试 C 应用程序与所有原始依赖项链接起来（诚然，这不会使库非常便携），还是有任何方法可以解决它，以便任何人都可以使用我的库，仅通过链接到我的libXXXXX.a 文件？

Answer 1

我是否应该将我的测试 C 应用程序与所有原始依赖项链接起来（诚然，这不会使库非常便携），

这是“技术上正确”的答案。这样做的原因是，否则，如果 C 应用程序想要使用另一个 D 库，该库在其依赖项中包含一些包，该包也是您的库中的依赖项，并且如果它以相同的方式链接（包括其所有依赖项它的静态库文件），这种依赖将在链接器输入中出现两次。即使您告诉链接器丢弃一个副本，也可能由于依赖于不同的不兼容版本等而出现问题。（请注意，有一个正在进行的 D SAOC project 来处理此问题。）

如果您假设 C 程序将使用的唯一 D 库是您的 Dub 包，那么您可以想象创建一个包含所有依赖项的静态库，尽管它可能需要包含 D 标准库和运行时嗯。