我的问题类似于这个，但也涉及静态库：
我们有一个交叉-platform 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 编程方面的专家，但据我在互联网上和其他工作开发人员那里了解到的情况，Windows 上的调试和发布版本之间存在这种（不寻常的？）区别。
显然，您不能将调试程序链接到发布库，反之亦然。
这是正确的吗？
好吧，为了清楚起见，让我再次总结一下这一切：
(1) 为我们的 C++ 编译器提供依赖 C 库的最佳方式是什么？
(2) 如果我们以后也想发布 C++ 库，那么让用户使用每个编译器从源代码构建是唯一可行的方法，对吧？
My question is similar to this one, but also regards static libraries:
We have a cross-platform C++ header library that builds nicely under Windows/Linux/Os X that works on multiple compilers and both 32 and 64 bit.
When the user has zlib or libbz2 installed, the build system enables some functionality in the library via #ifdefs.
To make it easier for our users, we want to ship libraries such as zlib and libbz2 for Windows, either in binary format or as source with few clicks to install.
(On Linux and Mac Os X, the libraries can simply be installed as system packages are in fact they are available in most standard installs, as far as I can tell).
The final solution should enable users to use Visual C/C++ compilers 2005, 2008 and 2010 as well as MinGW on 32 and 64 bit Windows to easily link against zlib and libbz2.
We are only concerned with C libraries at the moment and the foreseeable future.
The libraries should be built seperately, we do not want to integrate building them into our build system.
As far as I can see, there are at least two degrees of freedom here:
- Whether to use static libraries or DLLs.
- Whether to ship binary libraries or let users build their own libraries.
Another point is that users should be able to link the libraries both against debug and optimized versions of their program.
I am not an expert in Windows programming, but as far as I could find out on the internet and from other developers at work, there is this (unusual?) distinction between debug and release builds on Windows.
Apparently, you cannot link debug programs against release libraries and vice versa.
Is this correct?
Okay, so let me maybe summarize all this again for clarity:
(1) What is the best way to ship dependency C libraries for our C++ compiler?
(2) If we later also want to ship C++ libraries, letting the user build from source with each compiler is the only feasible way, right?
发布评论
评论（2）
没有完美的解决方案，但是如果提供 DLL 以及相应的头文件和导入库”。请注意，大多数编译器都提供了从 DLL 二进制文件创建导入库的工具。
您还可以以源代码形式提供库，并提供在不同编译器上构建它们的脚本。
一般来说，使用导出 C++ 类和方法的 DLL 是一个非常糟糕的主意，因为它们是以依赖于编译器的方式导出的，这实际上迫使您为每个受支持的编译器提供不同的 DLL。当我使用 C++ 库时，我采取以下措施：
如果我理解正确的话，您的用户就是正在构建应用程序的用户，您只需向他们提供标头库。因此，在我看来，在这种情况下，您需要记录他们如何将 C++ 库添加到其应用程序中，也许最好的方法是提供一个完全工作的示例应用程序，该应用程序也从源代码构建 C++ 库，至少针对 Visual Studio 和您知道用户可能使用的任何其他编译器。
祝你好运。
There is no perfect solution, but you will make it a lot easier for your users if ship DLLs, along with the corresponding header files and import libraries for the compilers that you think they'll be using, at least for Visual Studio. Note that most compilers provide tools to create an import library from a DLL binary.
You could also ship the libraries in source form, and provide a script that builds them on different compilers.
In general it is a very bad idea to use DLLs that export C++ classes and methods, since these are exported in a compiler dependent way, effectively forcing you to provide a different DLL for each supported compiler. I take the following measures when I work with C++ libraries:
If I understand this right, your users are the ones that are building an application, you are just providing them with your header library. So it seems to me in this case you will need to document how they can add a C++ library to their application, and maybe the best way to do that would be to provide a fully working sample application that also builds the C++ library from source, at least targeting Visual Studio and any other compilers that you know your users may use.
Good luck.
为了获得最大的二进制兼容性，最好的方法是将您的 c/c++ 库公开为 Windows 平台上的 COM
COM 对象可以从 C、C++ 和 .NET 语言中使用
For maximum binary compatibility the best way is to expose your c/c++ libaries as COM on Windows platform
COM objects can be consumed from C , C++ and .NET languages