链接器告诉我它不能解析符号,但它们在那里? [英] linker tells me it can't resolve symbols, but they're there?

查看:164
本文介绍了链接器告诉我它不能解析符号,但它们在那里?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我正在尝试使用我编写的库编译一个简单的测试应用程序。这在其他机器上编译并运行良好。



我在/ usr / lib下有libroller.so。我正在编译一个main.cpp文件:

  g ++ -g3 -Wall -I../../ -lrt -lroller -o rap main.o 

它抱怨很多错误,例如:

  /....../ main.cpp:51:未定义引用Log :: i(char const *,.. )'

然而,我知道这些存在于此:

  nm -Ca /usr/lib/libroller.so | grepLog :: i
00000000001f5d50 T Log :: i(char const *,...)
0000000000149530 W Log :: i(std :: string const&)

两者都是64位:

  file /usr/lib/libroller.so 
/usr/lib/libroller.so:ELF 64位LSB共享对象,x86-64,版本1(SYSV),动态链接,未剥离

文件main.o
main.o:ELF 64位LSB可重定位,x86-64,版本1(SYSV),未删除



编辑/回答:对象的顺序很重要。在库之前放置main.o是必要的。我猜连接器没有未解决的符号来处理,直到它到达main.o - 哪个是其列表中的最后一个对象。我仍然有点困惑,为什么这在其他机器上工作了好几个月......

解决方案

p>

  g ++ -g3 -Wall -I../../-lrt -lroller -o rap main.o $ b $ 



  g ++ -g3 -Wall main.o -lroller -lrt -o rap 

链接顺序很重要在这种情况下 -I 是多余的)。


I am trying to compile a simple test app using a library I've written. This compiles and runs fine on other machines.

I have libroller.so available at /usr/lib. I'm compiling a main.cpp as such:

g++ -g3 -Wall -I"../../" -lrt -lroller -o rap main.o

It complains of numerous errors such as:

/....../main.cpp:51: undefined reference to `Log::i(char const*, ...)'

However, I know that these exist in this so:

nm -Ca /usr/lib/libroller.so | grep "Log::i"            
00000000001f5d50 T Log::i(char const*, ...)
0000000000149530 W Log::i(std::string const&)

Both are 64 bit:

file /usr/lib/libroller.so           
/usr/lib/libroller.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, not stripped

file main.o   
main.o: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), not stripped

Unlike GCC and ld can't find exported symbols...but they're there! I'm pretty sure these symbols are defined. The same .so works with another using some of the same symbols.

EDIT/ANSWER: The order of objects is important. Placing main.o before the libraries was necessary. I'm guessing the linker had no unresolved symbols to deal with until it got to main.o -- which was the last object in its list. I'm still a little confused as to why this worked on other machines for many months...

解决方案

Change:

g++ -g3 -Wall -I"../../" -lrt -lroller -o rap main.o

to:

g++ -g3 -Wall main.o -lroller -lrt -o rap 

Link order matters (and the -I is redundant in this instance).

这篇关于链接器告诉我它不能解析符号,但它们在那里?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆