我的问题与此类似,但也涉及静态库:
我们有一个跨平台的 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++ 库,让用户使用每个编译器从源代码构建是唯一可行的方法,对吗?