我正在研究一组可重复使用的库，这些库需要作为静态库(.a 和 .lib)和动态库(.so 和 .dll)提供。
我希望动态库的依赖管理尽可能简单(你只需要一个动态库来满足你需要的每一点功能)，所以每个动态库所具有的所有功能依赖实际上都是静态链接到它。因此，动态库动态地向下游客户端提供它们的功能，但它们的上游依赖项是静态满足的。
所有这一切的结果是我的所有静态库都需要使用 -fPIC 进行编译，以便它们的代码适合链接到共享库中。我们使用的任何第三方库也是如此。它必须是静态库，使用 -fPIC 编译。
(我想，我可以构建我的库的 PIC 和非 PIC 变体 - 但我真的不想为每个目标平台编译库第三次 - 两次是相当(多)够了!)。
所以，这是我的问题:
我一直在尝试使用 -fPIC 将 boost_system 编译为静态库，但我不确定是否成功:
/b2 --build-type=complete variant=release link=static threading=multi runtime-link=static --layout=versioned --cxxflags=-fPIC
如预期的那样，此构建生成 .a 文件作为输出。但是，当我尝试将 boost 静态库链接到我的共享库之一时，我开始收到一条错误消息，指出 boost_system 不是位置独立代码:
.../dependencies/external/boost/1_54_0/stage/lib/linux_x86_64/libboost_system-gcc46-s-1_54.a(error_code.o):
relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC
但是，我已经(尝试)使用 -fPIC 构建 boost。有什么测试可以用来确定 libboost_system 是否真的是 PIC 代码？ IE。如果问题出在构建 boost - 或者将它链接到我的应用程序。
最佳答案
我相信您的问题可以通过删除启用 C++ 运行时库静态链接的命令行选项“runtime-link=static”来解决。由于您正在构建一个动态共享库对象，因此您希望避免这种行为，尤其是当客户端要从不同的 Linux 操作系统配置链接到您的库时。但是，选项“link=static”是可以的，应该保留。
关于c++ - 将 .o 库文件链接到共享对象时出现问题，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/17860484/