我正在开发一组可重用的库，这些库需要作为静态库（.a和amp; .lib）和动态库（.so＆amp; .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代码？即如果问题在于构建提升 - 或者将其链接到我的应用程序。
答案 0 :(得分：2)
我相信您的问题可以通过删除命令行选项“runtime-link = static”来解决，该选项启用C ++运行时库的静态链接。由于您正在构建动态共享库对象，因此您希望避免此行为，尤其是在客户端要从不同Linux OS配置链接到库时。但是，选项“link = static”是可以的，应该保留。