libgomp.so.1：无法打开共享对象文件答案

【问题标题】：libgomp.so.1: cannot open shared object filelibgomp.so.1：无法打开共享对象文件
【发布时间】：2013-02-02 12:27:34
【问题描述】：

我在我的 C++ 代码中使用 OpenMP。

libgomp.so.1 存在于我的 lib 文件夹中。我还将其路径添加到 LD_LIBRARY_PATH

仍然在运行时我收到错误消息：libgomp.so.1: 无法打开共享对象文件

在编译时，我使用 -fopenmp 选项编译我的代码。

知道什么会导致问题吗？

谢谢

【问题讨论】：

运行ldd your_application_name时输出什么？
我实际上是为一个不是 x86_64 的架构交叉编译它。但是还有另一个版本的 g++ 并且在另一个系统中一切正常。所以，我以前做过。只是不记得我是如何解决问题的！会不会和64bit 32bit有关？
我需要在编译时添加类似 -lgomp 的东西吗？
我认为-fopenmp 也会自动处理链接 libgomp。请参阅此问题的公认答案：stackoverflow.com/questions/6351961/specify-openmp-to-gcc
嗯，那（模拟器，交叉编译，...）是很多重要的信息，你没有包括在你的问题中。您的模拟器是否没有提供带有外壳等的完整系统？作为第一个修复，我会尝试使用-fopenmp -static 进行编译，如有必要，直接指定librt.a 和libgomp.a 的完整路径（同样，请参阅我发布的链接）。

【解决方案1】：

为您的程序使用静态链接。在您的情况下，这意味着使用-fopenmp -static，并在必要时指定相关librt.a 和libgomp.a 库的完整路径。

这解决了您的问题，因为静态链接只是将运行程序所需的所有代码与二进制文件打包在一起。因此，您的目标系统不需要查找任何动态库，即使它们是否存在于目标系统上也没关系。

请注意，静态链接并不是灵丹妙药。对于奇怪的硬件模拟器的特殊问题，它应该是一个好方法。然而，总的来说，静态链接有（至少）两个缺点：

二进制大小。想象一下，如果您静态链接所有 KDE 程序，那么您的系统上实际上将拥有所有 KDE/QT 库的数百个副本，而如果您使用共享库则可能只有一个副本
更新路径。假设人们在图书馆x 中发现了一个安全问题。使用共享库，只要在补丁可用时简单地更新库就足够了。如果您的所有应用程序都是静态链接的，您将不得不等待所有这些开发人员重新链接并重新发布他们的应用程序。

【讨论】：

非常感谢您的完整回答。当我在 LD_LIBRARY_PATH 中指定路径时，我仍然不明白为什么系统会在某些 .../bin/ld 中查找库。
@Computer_guy 我们也不知道，但如果您一次只提供一小部分相关信息，我们也很难猜出哪里出了问题。如果您想进一步诊断您的问题，请使用所有详细信息更新您的问题！（收到错误时使用的命令、错误消息、架构、模拟器……）