背景

当链接器在正常搜索中没有找到所需的符号，但该符号在直接指定的动态库的依赖项之一中可用时，命令行消息将显示DSO missing。

在过去，链接器认为具有特定语言依赖关系的符号是可用的。但在后来的一些版本中，这种情况发生了变化，现在链接器对可用内容执行了更严格的视图。因此，这一信息旨在帮助实现这一转变。

怎么办呢?

如果您是软件的维护者

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

如果你只是想编译软件

作为一种变通方法，可以使用选项-Wl，——copy-dt-needed-entries切换回更宽松的视图来查看可用的符号。

将此注入构建的常用方法是在运行configure或类似于此之前导出LDFLAGS:

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

有时直接传递LDFLAGS="-Wl，——copy-dt-needed-entries"给make也可以。

如果您正在使用cmake和使用过的pthread，请尝试添加以下行

find_package(Threads)
target_link_libraries(${CMAKE_THREAD_LIBS_INIT})

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

"LAPACK_LIB = - lapack -lblas"工作的地方 "LAPACK_LIB = -lblas - lapack"给出了上面描述的错误。

背景

当链接器在正常搜索中没有找到所需的符号，但该符号在直接指定的动态库的依赖项之一中可用时，命令行消息将显示DSO missing。

在过去，链接器认为具有特定语言依赖关系的符号是可用的。但在后来的一些版本中，这种情况发生了变化，现在链接器对可用内容执行了更严格的视图。因此，这一信息旨在帮助实现这一转变。

怎么办呢?

如果您是软件的维护者

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

如果你只是想编译软件

作为一种变通方法，可以使用选项-Wl，——copy-dt-needed-entries切换回更宽松的视图来查看可用的符号。

将此注入构建的常用方法是在运行configure或类似于此之前导出LDFLAGS:

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

有时直接传递LDFLAGS="-Wl，——copy-dt-needed-entries"给make也可以。

我发现有时候链接程序抱怨的库并不是引起问题的那个库。也许有一个聪明的方法来解决问题，但这就是我所做的:

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

@peter karasev:我在CentOS7上的gcc 4.8.2 cmake项目中遇到了同样的问题。“target_link_libraries”部分中的库的顺序很重要。我猜cmake只是将列表原样传递给链接器，也就是说，它不会尝试并计算出正确的顺序。这是合理的——当你思考它时，cmake不知道正确的顺序是什么，直到链接成功完成。

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

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是一个动态共享对象或共享库。