我一直在盯着谷歌搜索，但我看不到我做了什么。
我在32位机器上有一个工作项目。我刚刚将存储库拉到64位机器（这是该项目的原始开发机器），我现在在尝试构建测试二进制文件时遇到以下链接错误
/usr/bin/ld: error: /usr/lib/libboost_test_exec_monitor-mt.a(unit_test_log.o): requires dynamic R_X86_64_PC32 reloc against 'std::basic_string<char, std::char_traits<char>, std::allocator<char> >::_Rep::_S_create(unsigned long, unsigned long, std::allocator<char> const&)' which may overflow at runtime; recompile with -fPIC
/usr/bin/ld: error: /usr/lib/libboost_test_exec_monitor-mt.a(unit_test_log.o): requires unsupported dynamic reloc 11; recompile with -fPIC
我真的看不出我能改变什么。 boost库直接从ubuntu存储库中提取。任何有线索的人。
答案 0 :(得分：14)
您正在将静态库（Boost one）链接到动态库中。静态库通常不使用-fPIC构建，因为它们被假定仅链接到程序而不是另一个库。
在32位x86上，通过将与位置无关的代码部分重新定位到加载地址来静默修复此类代码;这使受影响的页面不可共享。为此，需要将重定位条目从链接时间转换为运行时重定位。
此转换在x86 64位上失败;这两个错误消息意味着
因此，链接器无法生成可加载的代码，并且理所当然地拒绝这样做。
要解决此问题，您需要链接到共享的libboost_test_exec_monitor-mt，或者自己构建一个静态库。
答案 1 :(得分：2)
共享库可以通过两种方式设置。一个是绝对地址，因此加载共享对象的每个二进制文件都获得它自己的共享代码副本，但调用没有额外的间接，并且尽可能快。另一种方式是使用“PIC”或位置无关代码。这增加了一个额外的间接层，但是共享库代码的一个副本可以为所有需要它的应用程序提供服务（因为额外的间接层是每个应用程序二进制文件）。
您所看到的是，当您尝试使用64位构建时，第一个选项的绝对地址无法强制使用特定的64位地址（可能代码中的某些目标文件不会支持64位地址）并且编译器告诉您已使用选项2并启用PIC。为了做到这一点，您需要使用-fPIC编译所有代码和库，假设g ++ / gcc。您可能还需要将库与-shared链接起来，但我不记得您必须这样做的确切时间。
答案 2 :(得分：0)
好的，Simon的回答确实帮助了我。
这个特定问题的最终解决方案是使用
libboost_unit_test_framework
（附带共享库）代替
libboost_test_exec_monitor
（没有）