我正在尝试交叉编译Tilera的源代码,并且在链接时出现以下错误。 所有这些错误都与C ++ STL(标准模板库)有关。
STL库的链接过程有什么不同吗?
错误是:
gtpu_t. a: In function `stlp_std::_Atomic_swap_struct<0>::_S_swap(unsigned int volatile* , unsigned int)':
91 /u/TILERA/TileraMDE-2.1.1.107611/tilepro/tile/usr/include/cpp/stl/stl/_threads.h :588: undefined reference to `stlp_std::_Atomic_swap_struct<0>::_S_swap_lock'
92 /u/TILERA/TileraMDE-2.1.1.107611/tilepro/tile/usr/include/cpp/stl/stl/_threads.h :588: undefined reference to `stlp_std::_Atomic_swap_struct<0>::_S_swap_lock'
93 /u/TILERA/TileraMDE-2.1.1.107611/tilepro/tile/usr/include/cpp/stl/stl/_threads.h :591: undefined reference to `stlp_std::_Atomic_swap_struct<0>::_S_swap_lock'
94 /u/TILERA/TileraMDE-2.1.1.107611/tilepro/tile/usr/include/cpp/stl/stl/_threads.h :591: undefined reference to `stlp_std::_Atomic_swap_struct<0>::_S_swap_lock'
95 /u/TILERA/LTESTACK/TILERA/DEV/lte/lte_enb/enb_app/../enb_gtpu/gtpu_t/lib/gtpu_t. a: In function `stlp_std::_Atomic_swap_struct<0>::_S_swap_ptr(void* volatile*, v oid*)':
96 /u/TILERA/TileraMDE-2.1.1.107611/tilepro/tile/usr/include/cpp/stl/stl/_threads.h :614: undefined reference to `stlp_std::_Atomic_swap_struct<0>::_S_swap_lock'
97 /u/TILERA/LTESTACK/TILERA/DEV/lte/lte_enb/enb_app/../enb_gtpu/gtpu_t/lib/gtpu_t. a:/u/TILERA/TileraMDE-2.1.1.107611/tilepro/tile/usr/include/cpp/stl/stl/_threads .h:614: more undefined references to `stlp_std::_Atomic_swap_struct<0>::_S_swap_ lock' follow
答案 0 :(得分:1)
我认为这会有所帮助。我之前尝试使用Tilera进行编译并得到类似的错误,“未定义引用”。解决方案是将库包含在项目属性中。
单击项目设置,转到路径和符号,库下包含stlp_std::_Atomic_swap_struct<0>::_S_swap_lock
定义的库。
另请注意,Tilera IDE(eclipse)很愚蠢。定义Tile库的路径不起作用!只需输入库的名称即可。 (假设您正确设置了IDE变量)。如果使用命令行,只需添加参数
即可包含库
-lMyLibrary
这是一个例子:
在图书馆下面有:
tmc
pthread
我假设您正在Linux下开发
答案 1 :(得分:0)
“STL”只是C ++实现的一部分。它不应该具体关联,就像您不需要专门链接malloc
或new
一样。
答案 2 :(得分:0)
如果我编译一个使用_S_swap_lock的小程序,它对我有用:
$ cat foo.cc
#include <rope>
int main(void)
{
std::crope r(100000, 'x');
std::crope r2 = r + "abc";
}
$ tile-c++ foo.cc
$ nm -C a.out | grep -i atomic
0000000000059028 V stlp_std::_Atomic_swap_struct<1>::_S_swap_lock
这是“&lt; 1&gt;”味道,对于32位原子,似乎是常用的。我没有看到&lt; 0&gt; libsupc ++中的味道。我怀疑你需要发布一些可以重现问题的代码。