c++ - 如何将第 3 个 C++ 方源代码编译为共享库

Question

我下载了第三方源代码，EDFlib ，并希望将其编译(使用 Visual Studio)到一个共享库中，并导出所有符号。

头文件如下所示:

#ifdef __cplusplus
extern "C" {
#endif

...
long long edftell(int handle, int edfsignal);
...


#ifdef __cplusplus
}
#endif

当我在 Visual Studio 中编译头文件和源文件时，没有生成 .lib(可能意味着没有导出符号)。

是否可以完全不修改库头文件，将其编译成一个共享库，并导出所有符号？当第 3 方团队发布新版本时，这将使切换到更新版本变得容易。

注意:

如果我自己创建了这个库，我会这样做:

#ifdef WIN32
    #ifdef EDFLIB_EXPORTS
        #define EDFLIB_API __declspec(dllexport)
    #else
        #define EDFLIB_API __declspec(dllimport)
    #endif
#else 
    #define EDFLIB_API
#endif

long long EDFLIB_API edftell(int handle, int edfsignal);

可以使用这些导出标志修改库头文件，但我不想修改它，我想找到一个替代方案。

Answer 1

对于更大的库，一个可能的解决方案是自动执行此任务，但这可能并不像看起来那么容易(C++ 中的非 POD 数据，enums，...)

如果你用一些最近的 GCC 编译(例如在 Linux 上)，您可以使用我的 GCC MELT 自定义它工具，或许可以通过生成一些 ed 脚本来修补 header 。这不是一件容易的事(可能需要几周的工作)，我建议只对一个相当大的库(例如一百万行 C++)采用这种方式，即使在这种情况下，它也可能不值得部分自动化的痛苦......

对于您的 EDFlib，最简单的方法是修补它们的 edflib.h文件(您可能需要在大约 30 个声明处添加 EDFLIB_API)并在 github 上提出拉取请求。

真正的问题是 Windows 和 POSIX(至少 Linux 和大多数 Unix，如 AIX、Solaris、HPUX)对 linker 的作用有不兼容的观点。和性质dynamic libraries (以及其中的符号)。莱文的 Linkers and Loaders这本书详细解释了这一点。这也是为什么我对完全自动化的方法持怀疑态度(开发人员是唯一知道应该导出什么以及如何导出的人；因此对于您的图书馆，您需要注释您的导出声明；最后，为 C++ 库制作 C 兼容的 API 通常需要一些重新设计和代码重构)。

注意。 GCC MELT 是 GCC 的插件，GCC 不允许在 Windows 上使用插件(但在 Linux 上允许)，正是因为您遇到的问题:用 __declspec(dllexport) 装饰每个导出的函数太痛苦了。