我的问题类似于 this one ，但也涉及静态库:
我们有一个跨平台的 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。
目前和可预见的 future ，我们只关心 C 库。
这些库应该单独构建，我们不想将构建它们集成到我们的构建系统中。
据我所知，这里至少有两个自由度:
另一点是用户应该能够将库链接到他们程序的调试版本和优化版本。
我不是 Windows 编程方面的专家，但据我在互联网上和其他工作中的开发人员那里找到的信息，Windows 上的调试和发布版本之间存在这种(不寻常的？)区别。
显然，您不能将调试程序链接到发布库，反之亦然。
这样对吗？
好的，为了清楚起见，让我再次总结一下:
(1) 为我们的 C++ 编译器提供依赖 C 库的最佳方式是什么？
(2) 如果我们以后还想发布 C++ 库，让用户使用每个编译器从源代码构建是唯一可行的方法，对吗？
最佳答案
没有完美的解决方案，但如果提供 DLL 以及相应的头文件和 import libraries 用于您认为他们将使用的编译器，至少对于 Visual Studio，您的用户会更容易。请注意，大多数编译器都提供了从 DLL 二进制文件创建导入库的工具。
您还可以以源代码形式提供库，并提供在不同编译器上构建它们的脚本。
一般来说，使用导出 C++ 类和方法的 DLL 是一个非常糟糕的主意，因为它们以依赖于编译器的方式导出，有效地迫使您为每个受支持的编译器提供不同的 DLL。我在使用 C++ 库时采取以下措施:
如果我理解正确，您的用户就是构建应用程序的用户，您只是向他们提供您的头库。所以在我看来，在这种情况下，您需要记录他们如何将 C++ 库添加到他们的应用程序中，也许最好的方法是提供一个完全工作的示例应用程序，该应用程序也从源代码构建 C++ 库，至少针对 Visual Studio 和您知道用户可能使用的任何其他编译器。
祝你好运。
关于c++ - Windows 上 C 库的二进制交叉编译器兼容性，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/7940200/