如何强制编译 Boost 以使用 -fPIC答案

【问题标题】：how to force compilation of Boost to use -fPIC如何强制编译 Boost 以使用 -fPIC
【发布时间】：2015-01-08 19:31:42
【问题描述】：

我所在的团队制作了一个用于 Python 的共享库。这个库完全是 C++，我们使用 Boost 来暴露给 python。因为我们不能保证我们的客户已经安装了 Boost 库，所以我们将 Boost 所需的功能静态地引入到共享对象文件中。编译的最后阶段对许多人来说看起来很熟悉

g++ -o <output> <objects> -Wl,-Bstatic -lboost_python -lboost_regex ... -Wl,-Bdynamic -shared <other_opts>

我们传统上使用我们自己构建的 Boost：1.47。这个版本现在已经很老了，所以我们希望更新。然而，奇怪的是，当我在我的 CentOS 7 系统上使用 yum 安装必要的对象时，我从 gcc 收到以下错误：

relocation R_X86_64_32 against '.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC

好吧，我想我只需下载最新的 boost（CentOS 7 安装 Boost 1.53）并自己构建。毕竟，这一直对我们有用。我关注instructions here，但我遇到了同样的错误。即使是它构建的静态库，我如何强制使用 -fPIC？

【问题讨论】：

您确定 gcc（或运行时的可执行文件）正在查找自定义构建的 Boost 库吗？您可以在 gcc 中使用 -L 或在运行时使用 LD_LIBRARY_PATH 修改库搜索目录。
您可以使用 cxxflags="-fPIC" 直接提升构建以使用编译器标志。有一个类似的变量名为linkflags。请参阅 boost.org/build/doc/html/bbv2/overview/invocation.html 的 boost 构建文档
@NicholasM 是的，我确信我的库正在被 ld 使用。我正在使用 ld 的 -L 选项来强制执行此操作。非常感谢您提供的链接。我使用的链接没有提到这一点。
“因为我们不能保证我们的客户安装了 Boost 库” 这就是我们发布依赖项的原因吗？在 RPM 的 .spec 文件中命名它们？
@lightnessracesinorbit。这正是我最终决定要做的事情。

标签： c++ boost

【解决方案1】：

我相信 boost 在编译共享库（.so 文件）时会自动使用-fPIC，但下面的命令在编译静态库（.a 文件）时也会使用-fPIC。

这在 boost 1.46.1 上对我有用：

sudo ./bjam cxxflags=-fPIC cflags=-fPIC -a ... install

... 是您添加其他标志的位置，例如 threading=multi 或 --layout=tagged，以及可选的要构建的项目列表（例如：--with-regex）。

注意：不需要同时使用cflags 和cxxflags，只需要一个即可。请参阅下面的 cmets。

参考链接：

【讨论】：

Boost 1.61.0: cflags 似乎是多余的。此外，sudo 对于本地（即非系统范围）安装应该是冗余的。
@smbear 我同意cflags 可能是多余的。我不确定我是否需要它，但它似乎没有伤害。
cxxflags 是 C++ 和 cflags C 和 C++。所以 cxxflags 在技术上是多余的，因为它被严格暗示，但是 Boost 是 C++，所以它们是一样的。

【解决方案2】：

为了方便，我把之前的答案和 cmets 结合起来了：

sudo ./bjam cxxflags=-fPIC -a --with-system install

--with-system 不是必须的，但它是一个可以添加其他 boost 编译选项的地方

它适用于 CentOS 7 和 boost 1.67

【讨论】：

【解决方案3】：

另一种解决方案：

./bootstrap.sh
./b2 cxxflags=-fPIC cflags=-fPIC

【讨论】：