时间戳

首页 > 解决方案 > 将 D 项目编译为库 - 依赖项会发生什么？

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

问题描述

好的，这是我的问题：

我有一个工作的 DUB 项目，它产生一个应用程序。我决定在我的dub.json文件中还需要一个“库”配置：

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

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

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

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

因此，我使用编译我的 C 应用程序gcc -c ctest.c，然后将它们链接在一起，如dmd libMYLIBRARY.a ctest.o.

现在，问题来了：

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

所以，问题是......我该如何解决这个问题？

我的意思是...我是否应该将我的测试 C 应用程序与所有原始依赖项链接起来（诚然，这不会使库非常便携），或者有什么办法可以解决它，以便任何人都可以使用我的库，只有通过链接反对我的libXXXXX.a档案？

标签： cgccddmddub

解决方案

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

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

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

推荐阅读