243

当我在编译 openvswitch-1.5.0 时,我遇到了以下编译错误:

 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

如果我尝试查看 的符号libpthread,它看起来不错。

$ 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

您能否提供任何提示或指示?

4

16 回答 16

195

您应该在编译目标文件在命令行中提及该库:

 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 

说明:链接取决于模块的顺序。首先请求符号,然后从包含它们的库中链接。所以你必须指定首先使用库的模块,然后是它们之后的库。像这样:

gcc x.o y.o z.o -la -lb -lc

此外,如果存在循环依赖,您应该在命令行上多次指定同一个库。因此,如果libb需要 symbol fromlibclibc需要 symbol from libb,命令行应该是:

gcc x.o y.o z.o -la -lb -lc -lb
于 2013-11-11T11:53:57.003 回答
56

错误消息取决于发行版/编译器版本:

Ubuntu 俏皮:

/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:(更多信息)

/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

解决方案:在链接阶段,您可能在编译步骤中缺少库。就我而言,我在 makefile / GCC 标志中添加了“-lz”。

背景: DSO 是动态共享对象或共享库。

于 2013-11-26T00:34:26.733 回答
45

背景

DSO missing from command line当链接器通过正常搜索找不到所需符号但该符号在直接指定的动态库的依赖项之一中可用时,将显示该消息。

过去,链接器认为指定语言的依赖项中的符号是可用的。但在后来的一些版本中,这种情况发生了变化,现在链接器对可用的内容进行了更严格的查看。因此,该消息旨在帮助实现这一转变。

该怎么办?

如果您是软件的维护者

您应该通过确保在链接器命令行上直接指定满足所需符号所需的所有库来解决此问题。还要记住,顺序通常很重要。

如果你只是想编译软件

作为一种解决方法,可以使用选项切换回更宽松的可用符号视图-Wl,--copy-dt-needed-entries

将其注入构建的常用方法是在运行之前导出 LDFLAGSconfigure或类似这样:

export LDFLAGS="-Wl,--copy-dt-needed-entries"

有时LDFLAGS="-Wl,--copy-dt-needed-entries"直接传递给make也可能有效。

于 2019-03-10T10:18:34.660 回答
14

我发现了另一个案例,因此我认为你们都错了。

这就是我所拥有的:

/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

问题是命令行不包含-lX11- 尽管 libX11.so 应该作为依赖项添加,因为参数中还有 GTK 和 GNOME 库。

所以,对我来说唯一的解释是这条消息可能是为了帮助你,但它没有正确地做到这一点。这可能很简单:提供符号的库没有添加到命令行。

请注意关于 POSIX 中链接的三个重要规则:

  • 动态库已定义依赖关系,因此只能以任何顺序提供来自顶级依赖关系的库(尽管在静态库之后)
  • 静态库只有未定义的符号 - 取决于您了解它们的依赖关系并在命令行中提供所有它们
  • 静态库中的顺序始终是:请求者优先提供者随后。否则,您将收到未定义的符号消息,就像您忘记将库添加到命令行时一样
  • 当您使用 指定库时-l<name>,您永远不知道它是否会采用lib<name>.solib<name>.a。动态库是首选,如果找到的话,静态库只能由编译器选项强制执行——仅此而已。而你有没有上述问题,就看你有静态库还是动态库了
  • 好吧,有时动态库中可能缺少依赖项:D
于 2016-07-14T13:34:08.920 回答
8

我也遇到了同样的问题。我不知道为什么,我只是-lpthread在编译器中添加了选项,一切正常。

老的:

$ g++ -rdynamic -m64 -fPIE -pie  -o /tmp/node/out/Release/mksnapshot ...*.o *.a -ldl -lrt

出现以下错误。如果我将选项附加-lpthread到上述命令,则可以。

/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
于 2016-08-29T16:43:32.800 回答
7

我发现我有同样的错误。我正在用 lapack 和 blas 编译代码。当我切换调用这两个库的顺序时,错误消失了。

“LAPACK_LIB = -llapack -lblas”在“LAPACK_LIB = -lblas -llapack”给出上述错误的情况下工作。

于 2013-12-17T19:30:29.683 回答
3

我发现有时链接器抱怨的库不是导致问题的库。可能有一种聪明的方法可以找出问题所在,但这就是我所做的:

  • 注释掉链接命令中的所有链接库。
  • 清除所有 .o、.so 等(通常 make clean 就足够了,但您可能需要运行递归 find + rm 或类似的东西)。
  • 一次取消注释链接命令中的库,并根据需要重新排列顺序。

@peter karasev:我在 CentOS7 上的 gcc 4.8.2 cmake 项目中遇到了同样的问题。“target_link_libraries”部分中库的顺序很重要。我猜cmake只是将列表按原样传递给链接器,即它不会尝试计算出正确的顺序。这是合理的 - 当您考虑它时,cmake 在链接成功完成之前无法知道正确的顺序是什么。

于 2015-02-05T09:31:04.613 回答
3

如果您使用的是 CMake,有一些方法可以解决它:

解决方案1:最优雅的一个

add_executable(...)
target_include_directories(...)
target_link_libraries(target_name pthread)

解决方案 2:使用 CMakefind_package

find_package(Threads REQUIRED) # this will generate the flag for CMAKE_THREAD_LIBS_INIT

add_executable(...)
target_include_directories(...)
target_link_libraries(target_name ${CMAKE_THREAD_LIBS_INIT})

解决方案 3:更改 CMake 标志

# e.g. with C++ 17, change to other version if you need
set(CMAKE_CXX_STANDARD 17)
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++17 -pthread")
于 2020-04-21T15:02:52.760 回答
2

请补充:CFLAGS="-lrt"LDFLAGS="-lrt"

于 2017-04-13T08:16:12.113 回答
2

在处理使用数学函数的代码时,您还应该链接它们。在我的情况下,我在编译时提供了以下内容,这对我有用。

mpicc -o testname testname.c -lm
于 2021-06-12T13:17:04.680 回答
1

当我distcc用来制作我的 c++ 项目时,我也遇到了同样的问题;最后我用export CXX="distcc g++".

于 2018-02-09T04:24:54.483 回答
1

尝试在Makefile-pthread的库列表末尾添加。

它对我有用。

于 2019-11-21T08:57:07.437 回答
1

如果您正在使用 cmake 并使用 pthreads,请尝试添加以下行

find_package(Threads)
target_link_libraries(${CMAKE_THREAD_LIBS_INIT})
于 2020-02-01T14:56:06.600 回答
0

当我安装 HPCC 基准测试(包括 HPL 和其他一些基准测试)时,同样的事情发生在我身上。我在构建脚本中添加-lm了编译器标志,然后成功编译。

于 2016-12-04T18:41:04.553 回答
0

如果使用,g++请确保您没有运行gcc

于 2018-06-21T22:46:04.163 回答
0

改为使用 g++ 编译。它在我从 gcc 切换到 g++ 的情况下有效。

于 2021-07-02T15:34:44.167 回答