未定义的引用 - 尽管链接器找到了 lib [英] Undefined reference - despite lib being found by linker
问题描述
我有一个简单的程序来测试 python 开发文件的可用性:
I have a trivial program to test for availability of python development files:
#include<Python.h>
int main(){Py_Initialize(); Py_Finalize(); }
我将它(安装了 python 2.7)编译为 gcc -I/usr/include/python2.7 -lpython2.7 p.c
.它在其他机器上运行良好,除了在 Ubuntu 12.04(精确)的大部分干净的 chroot 上我不断得到
I compile it (with python 2.7 installed) as gcc -I/usr/include/python2.7 -lpython2.7 p.c
. It works fine on other machines, except that at mostly-clean chroot of Ubuntu 12.04 (precise) I keep getting
/tmp/ccj8Mgjb.o: In function `main':
p.c:(.text+0x5): undefined reference to `Py_Initialize'
p.c:(.text+0xa): undefined reference to `Py_Finalize'
collect2: ld returned 1 exit status
头文件已安装,/usr/lib/libpython2.7.so
存在,但链接器仍然失败.该符号列在.so
文件中,gcc正在读取正确的libpython2.7.so
:
Headers are installed, /usr/lib/libpython2.7.so
exists but the linker nevertheless fails. The symbol is listed in the .so
file, and gcc is reading the right libpython2.7.so
:
$ nm -D libpython2.7.so.1.0 | grep Py_Initialize
00000000000c9c20 T Py_Initialize
00000000000c9260 T Py_InitializeEx
$ strace -f gcc -I/usr/include/python2.7 -lpython2.7 /tmp/p.c 2>&1 |grep libpython2.7 |grep open
[pid 10618] open("/usr/lib/gcc/x86_64-linux-gnu/4.6/libpython2.7.so", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 10618] open("/usr/lib/gcc/x86_64-linux-gnu/4.6/libpython2.7.a", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 10618] open("/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../x86_64-linux-gnu/libpython2.7.so", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 10618] open("/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../x86_64-linux-gnu/libpython2.7.a", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 10618] open("/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../lib/libpython2.7.so", O_RDONLY) = 7
有什么想法吗?
推荐答案
试试:
gcc -I/usr/include/python2.7 p.c -lpython2.7
链接器在加载 libpython2.7.a
时还不知道 Py_Initialize
是必需的符号,因此将其丢弃.然后它到达 p.o 并抛出一个关于丢失符号的适合.以这种方式排序将让链接器在后续输入中查找丢失的符号.
the linker doesn't yet know that Py_Initialize
is a required symbol when it loads libpython2.7.a
, so it tosses it away. And then it gets to p.o and throws a fit about the missing symbol. Ordering it this way will let the linker look for the missing symbol in subsequent inputs.
参见:http://gcc.gnu.org/onlinedocs/gcc/Link-Options.html
在命令的哪个位置编写此选项会有所不同;链接器按照指定的顺序搜索和处理库和目标文件.因此,foo.o -lz bar.o' 在文件 foo.o 之后但在 bar.o 之前搜索库
z'.如果 bar.o 引用了 `z' 中的函数,这些函数可能不会被加载.
It makes a difference where in the command you write this option; the linker searches and processes libraries and object files in the order they are specified. Thus,
foo.o -lz bar.o' searches library
z' after file foo.o but before bar.o. If bar.o refers to functions in `z', those functions may not be loaded.
这篇关于未定义的引用 - 尽管链接器找到了 lib的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!