1

我正在研究一组需要作为静态库(.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 构建提升。有什么测试可以用来确定 libboost_system 是否真的是 PIC 代码?即,如果问题在于构建提升 - 或将其链接到我的应用程序。

4

1 回答 1

2

我相信您的问题可以通过删除启用 C++ 运行时库的静态链接的命令行选项“runtime-link=static”来解决。由于您正在构建动态共享库对象,因此您希望避免这种行为,尤其是当客户端要从不同的 Linux 操作系统配置链接到您的库时。但是,选项“link=static”是可以的,应该保留。

于 2017-01-06T00:19:21.383 回答