4

我的问题与类似,但也涉及静态库:

我们有一个跨平台的 C++ 头库,它可以在 Windows/Linux/Os X 下很好地构建,适用于多个编译器,包括 32 位和 64 位。当用户安装了 zlib 或 libbz2 时,构建系统通过#ifdefs.

为了让我们的用户更容易使用,我们希望以二进制格式或作为源代码发布用于 Windows 的 zlib 和 libbz2 等库,只需点击几下即可安装。(在 Linux 和 Mac Os X 上,库可以简单地安装,因为系统包实际上在大多数标准安装中都可用,据我所知)。

最终的解决方案应该使用户能够在 32 位和 64 位 Windows 上使用 Visual C/C++ 编译器 2005、2008 和 2010 以及 MinGW,以便轻松链接到 zlib 和 libbz2。我们目前只关心 C 库和可预见的未来。

这些库应该单独构建,我们不想将构建它们集成到我们的构建系统中。

据我所知,这里至少有两个自由度:

  • 是否使用静态库或 DLL。
  • 是发布二进制库还是让用户构建自己的库。

另一点是用户应该能够将库链接到他们程序的调试和优化版本。我不是 Windows 编程方面的专家,但据我在 Internet 上和其他工作中的开发人员那里了解到,Windows 上的调试和发布版本之间存在这种(不寻常的?)区别。显然,您不能将调试程序与发布库链接,反之亦然。它是否正确?

好的,为了清楚起见,让我再次总结一下:(1)为我们的 C++ 编译器提供依赖 C 库的最佳方式是什么? (2) 如果我们以后还想发布 C++ 库,让用户使用每个编译器从源代码构建是唯一可行的方法,对吗?

4

2 回答 2

2

为我们的 C++ 编译器提供依赖 C 库的最佳方式是什么?

没有完美的解决方案,但如果为您认为他们将使用的编译器(至少对于 Visual Studio)提供 DLL 以及相应的头文件和导入库,您的用户会更轻松。请注意,大多数编译器都提供了从 DLL 二进制文件创建导入库的工具。

您还可以以源代码形式发布库,并提供在不同编译器上构建它们的脚本。

如果我们以后还想发布 C++ 库,让用户使用每个编译器从源代码构建是唯一可行的方法,对吧?

一般来说,使用导出 C++ 类和方法的 DLL 是一个非常糟糕的主意,因为它们是以编译器相关的方式导出的,实际上迫使您为每个受支持的编译器提供不同的 DLL。在使用 C++ 库时,我采取了以下措施:

  1. 构建静态库,而不是 DLL。
  2. 将 C++ 库的构建合并到我的项目的构建中(例如,作为依赖项目),确保所有内容都由相同的编译器构建。

如果我理解这一点,您的用户就是构建应用程序的用户,您只是为他们提供了您的标头库。所以在我看来,在这种情况下,您需要记录他们如何将 C++ 库添加到他们的应用程序中,也许最好的方法是提供一个完全工作的示例应用程序,该应用程序还可以从源代码构建 C++ 库,至少针对 Visual Studio 和您知道您的用户可能使用的任何其他编译器。

祝你好运。

于 2011-10-29T17:55:42.243 回答
1

为了获得最大的二进制兼容性,最好的方法是在 Windows 平台上将您的 c/c++ 库作为 COM 公开

COM 对象可以从 C、C++ 和 .NET 语言中使用

于 2011-10-29T17:23:22.227 回答