可以将文章内容翻译成中文,广告屏蔽插件可能会导致该功能失效(如失效,请关闭广告屏蔽插件后再试):
问题:
When I'm compiling openvswitch-1.5.0, I've encountered the following compile error:
gcc -Wstrict-prototypes -Wall -Wno-sign-compare -Wpointer-arith -Wdeclaration-after-statement -Wformat-security -Wswitch-enum -Wunused-parameter -Wstrict-aliasing -Wbad-function-cast -Wcast-align -Wstrict-prototypes -Wold-style-definition -Wmissing-prototypes -Wmissing-field-initializers -Wno-override-init -g -O2 -export-dynamic ***-lpthread*** -o utilities/ovs-dpctl utilities/ovs-dpctl.o lib/libopenvswitch.a /home/jyyoo/src/dpdk/build/lib/librte_eal.a /home/jyyoo/src/dpdk/build/lib/libethdev.a /home/jyyoo/src/dpdk/build/lib/librte_cmdline.a /home/jyyoo/src/dpdk/build/lib/librte_hash.a /home/jyyoo/src/dpdk/build/lib/librte_lpm.a /home/jyyoo/src/dpdk/build/lib/librte_mbuf.a /home/jyyoo/src/dpdk/build/lib/librte_ring.a /home/jyyoo/src/dpdk/build/lib/librte_mempool.a /home/jyyoo/src/dpdk/build/lib/librte_malloc.a -lrt -lm /usr/bin/ld: /home/jyyoo/src/dpdk/build/lib/librte_eal.a(eal.o): undefined reference to symbol 'pthread_create@@GLIBC_2.2.5' /lib/x86_64-linux-gnu/libpthread.so.0: error adding symbols: DSO missing from command line
If I try to see the symbols of libpthread
, it looks fine.
$ readelf -s /lib/x86_64-linux-gnu/libpthread.so.0 | grep pthread_create 199: 0000000000008220 2814 FUNC GLOBAL DEFAULT 13 pthread_create@@GLIBC_2.2.5 173: 0000000000008220 2814 FUNC LOCAL DEFAULT 13 __pthread_create_2_1 462: 0000000000008220 2814 FUNC GLOBAL DEFAULT 13 pthread_create@@GLIBC_2.2
Could you give any hints or pointers?
回答1:
You should mention the library on the command line after the object files being compiled:
gcc -Wstrict-prototypes -Wall -Wno-sign-compare -Wpointer-arith -Wdeclaration-after-statement -Wformat-security -Wswitch-enum -Wunused-parameter -Wstrict-aliasing -Wbad-function-cast -Wcast-align -Wstrict-prototypes -Wold-style-definition -Wmissing-prototypes -Wmissing-field-initializers -Wno-override-init \ -g -O2 -export-dynamic -o utilities/ovs-dpctl utilities/ovs-dpctl.o \ lib/libopenvswitch.a \ /home/jyyoo/src/dpdk/build/lib/librte_eal.a /home/jyyoo/src/dpdk/build/lib/libethdev.a /home/jyyoo/src/dpdk/build/lib/librte_cmdline.a /home/jyyoo/src/dpdk/build/lib/librte_hash.a /home/jyyoo/src/dpdk/build/lib/librte_lpm.a /home/jyyoo/src/dpdk/build/lib/librte_mbuf.a /home/jyyoo/src/dpdk/build/lib/librte_ring.a /home/jyyoo/src/dpdk/build/lib/librte_mempool.a /home/jyyoo/src/dpdk/build/lib/librte_malloc.a \ -lrt -lm -lpthread
Explanation: the linking is dependent on the order of modules. Symbols are first requested, and then linked in from a library that has them. So you have to specify modules that use libraries first, and libraries after them. Like this:
gcc x.o y.o z.o -la -lb -lc
Moreover, in case there's a circular dependency, you should specify the same library on the command line several times. So in case libb
needs symbol from libc
and libc
needs symbol from libb
, the command line should be:
gcc x.o y.o z.o -la -lb -lc -lb
回答2:
Google lead me here.. so for others with a similar problem
Ubuntu Saucy: Vague error similar to yours
/usr/bin/ld: /mnt/root/ffmpeg-2.1.1//libavformat/libavformat.a(http.o): undefined reference to symbol 'inflateInit2_' /lib/x86_64-linux-gnu/libz.so.1: error adding symbols: DSO missing from command line
Ubuntu Raring: I got a more informative error message
/usr/bin/ld: note: 'uncompress' is defined in DSO /lib/x86_64-linux-gnu/libz.so.1 so try adding it to the linker command line
Solution: add '-lz' to your makefile / GCC flags. In other words, your simply missing a library in your compilation steps, during the linking stage.
To expand, DSO is a dynamic shared object, or a shared library in other words
回答3:
I found another case and therefore I thing you are all wrong.
This is what I had:
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: eggtrayicon.o: undefined reference to symbol 'XFlush' /usr/lib64/libX11.so.6: error adding symbols: DSO missing from command line
The problem is that the command line DID NOT contain -lX11
- although the libX11.so should be added as a dependency because there were also GTK and GNOME libraries in the arguments.
So, the only explanation for me is that this message might have been intended to help you, but it didn't do it properly. This was probably simple: the library that provides the symbol was not added to the command line.
Please note three important rules concerning linkage in POSIX:
- Dynamic libraries have defined dependencies, so only libraries from the top-dependency should be supplied in whatever order (although after the static libraries)
- Static libraries have just undefined symbols - it's up to you to know their dependencies and supply all of them in the command line
- The order in static libraries is always: requester first, provider follows. Otherwise you'll get undefined symbol message, just like when you forgot to add the library to the command line
- When you specify the library with
-l
, you never know whether it will take lib.so
or lib.a
. The dynamic library is preferred, if found, and static libraries only can be enforced by compiler option - that's all. And whether you have any problems as above, it depends on whether you had static or dynamic libraries - Well, sometimes the dependencies may be lacking in dynamic libraries :D
回答4:
I found I had the same error. I was compiling a code with both lapack and blas. When I switched the order that the two libraries were called the error went away.
"LAPACK_LIB = -llapack -lblas" worked where "LAPACK_LIB = -lblas -llapack" gave the error described above.
回答5:
What I have found is that sometimes the library that the linker complains about is not the one causing the problem. Possibly there is a clever way to work out where the problem is but this is what I do:
- Comment out all the linked libraries in the link command.
- Clean out all .o's, .so's etc (Usually make clean is enough, but you may want to run a recursive find + rm, or something similar).
- Uncomment the libraries in the link command one at a time and re-arrange the order as necessary.
@peter karasev: I have come across the same problem with a gcc 4.8.2 cmake project on CentOS7. The order of the libraries in "target_link_libraries" section is important. I guess cmake just passes the list on to the linker as-is, i.e. it doesn't try and work out the correct order. This is reasonable - when you think about it cmake can't know what the correct order is until the linking is successfully completed.
回答6:
I also encountered same problem. I do not know why, i just add -lpthread
option to compiler and everything ok.
Old:
$ g++ -rdynamic -m64 -fPIE -pie -o /tmp/node/out/Release/mksnapshot ...*.o *.a -ldl -lrt
got following error. If i append -lpthread
option to above command then OK.
/usr/bin/ld: /tmp/node/out/Release/obj.host/v8_libbase/deps/v8/src/base/platform/condition-variable.o: undefined reference to symbol 'pthread_condattr_setclock@@GLIBC_2.3.3' //lib/x86_64-linux-gnu/libpthread.so.0: error adding symbols: DSO missing from command line collect2: error: ld returned 1 exit status
回答7:
Please add: CFLAGS="-lrt"
and LDFLAGS="-lrt"
回答8:
The same thing happened to me as I was installing the HPCC benchmark (includes HPL and a few other benchmarks). I added -lm
to the compiler flags in my build script and then it successfully compiled.
回答9:
The same problem happened to me when I use distcc
to make my c++ project; Finally I solved it with export CXX="distcc g++"
.