加载共享库时发生Linux错误：无法打开共享目标文件：没有这样的文件或目录
程序是Xenomaitesting套件的一部分，从Linux PC与Linux + Xenomai ARM工具链交叉编译。
# echo $LD_LIBRARY_PATH /lib # ls /lib ld-2.3.3.so libdl-2.3.3.so libpthread-0.10.so ld-linux.so.2 libdl.so.2 libpthread.so.0 libc-2.3.3.so libgcc_s.so libpthread_rt.so libc.so.6 libgcc_s.so.1 libstdc++.so.6 libcrypt-2.3.3.so libm-2.3.3.so libstdc++.so.6.0.9 libcrypt.so.1 libm.so.6 # ./clocktest ./clocktest: error while loading shared libraries: libpthread_rt.so.1: cannot open shared object file: No such file or directory 编辑：好的，我没有注意到最后的.1是文件名的一部分。 这是什么意思呢？
更新虽然我在下面写的是关于共享库的一般回答，但我认为这类消息最常见的原因是因为你已经安装了一个包，但没有安装该包的“-dev”版本。
那么，这不是谎言 – 在该清单中没有libpthread_rt.so.1 。 您可能需要重新configuration并重新构build它，以便依赖于您拥有的库，或者安装提供的任何libpthread_rt.so.1 。
一般而言，.so之后的数字是版本号，而且您经常会发现它们是相互之间的符号链接，所以如果您拥有libfoo.so的1.1版本，那么您将拥有一个真正的文件libfoo.so.1.0，和符号链接foo.so和foo.so.1指向libfoo.so.1.0。 如果你安装了1.1版而不删除另一个版本，你将会得到一个libfoo.so.1.1，而libfoo.so.1和libfoo.so现在将指向新版本，但是任何需要精确版本的代码都可以使用libfoo.so.1.0文件。 只依赖版本1 API的代码，但不关心它是1.0还是1.1会指定libfoo.so.1。 正如orip在评论中指出的那样，在http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html中有很好的解释。;
在你的情况下，你可能会把 libpthread_rt.so.1链接到libpthread_rt.so 。 但是，不能保证它不会破坏你的代码，吃你的电视晚餐。
你的图书馆是一个dynamic图书馆。 您需要告诉操作系统在运行时可以find它的位置。
为此，我们需要完成以下简单的步骤：
（1）如果你不知道图书馆的位置，找出它的位置。
cd / sudo find ./ | grep the_name_of_the_file.so
（2）检查是否存在dynamic库path环境variables（ LD_LIBRARY_PATH ）
$ echo $LD_LIBRARY_PATH
如果没有什么要显示的话，可以添加一个默认的path值（或者，如果你愿意的话）
$ LD_LIBRARY_PATH=/usr/local/lib
（3）添加欲望path，导出并尝试应用程序。
请注意，path应该是path.so.something所在的目录。 所以如果path.so.something在/my_library/path.so.something它应该是：
$ LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/my_library/ $ export LD_LIBRARY_PATH $ ./my_app
来源： http ： //www.gnu.org/software/gsl/manual/html_node/Shared-Libraries.html
以下是您可以尝试的一些解决scheme：
LDCONFIG
正如AbiusX指出的那样：如果你刚才安装了这个库，你可能只需要运行ldconfig 。
sudo ldconfig
ldconfig创build必要的链接并caching到在命令行上指定的目录中find的最新共享库，位于文件/etc/ld.so.conf和受信任的目录（/ lib和/ usr / lib）中。
通常你的软件包pipe理器会在你安装一个新的库的时候处理这个问题，但并不总是这样，即使这不是你的问题，也不会伤害到运行ldconfig。
开发包或错误的版本
如果这不起作用，我也会检查保罗的build议，并寻找图书馆的“-dev”版本。 许多库分为开发包和非开发包。 你可以使用这个命令来查找它：
apt-cache search <libraryname>
如果您只是安装了错误的库版本，也可以提供帮助。 一些库同时发布在不同的版本中，例如Python。
图书馆位置
如果您确定安装了正确的软件包，并且ldconfig没有find它，则可能只是在非标准目录中。 缺省情况下，ldconfig将在/etc/ld.so.conf和$LD_LIBRARY_PATH列出的/lib ， /usr/lib和目录中查找。 如果你的库在别的地方，你可以在/etc/ld.so.conf自行添加这个目录，把这个库的path附加到$LD_LIBRARY_PATH ，或者把这个库移到/usr/lib 。 然后运行ldconfig 。
要找出库的位置，试试这个：
sudo find / -iname *libraryname*.so*
（用库的名称replacelibraryname ）
如果使用$LD_LIBRARY_PATH路由，则需要将其放入~/.bashrc文件中，以便每次login时运行该文件：
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/path/to/library
我有类似的错误，我可以通过给予解决，
sudo ldconfig -v
希望这可以帮助。
您需要确保在编译.c文件时在链接期间指定库path：
gcc -I / usr / local / include xxx.c -o xxx -L / usr / local / lib -Wl，-R / usr / local / lib
-Wl，-R部分告诉生成的二进制文件在运行时在/ usr / local / lib中查找库，然后尝试使用/ usr / lib /
希望它会帮助你。
linux.org参考页面解释了这个机制，但是并没有解释它背后的动机:-(
为此，请参阅Sun链接器和库指南
另外，请注意，“外部版本控制”在Linux上基本已经过时，因为符号版本控制（GNU扩展）允许您在同一个库中存在同一个函数的多个不兼容版本。 这个扩展允许glibc在过去的10年里拥有相同的外部版本： libc.so.6 。
尝试在〜/ .bashrc中添加export LD_LIBRARY_PATH = path_to_your_library
有用！
cd /home/<user_name>/ sudo vi .bash_profile
在最后添加这些行
LD_LIBRARY_PATH=/usr/local/lib:<any other paths you want> export LD_LIBRARY_PATH
另一种可能的解决scheme取决于你的情况
如果您知道libpthread_rt.so.1与libpthread_rt.so相同，则可以通过以下方式创build符号链接：
ln -s /lib/libpthread_rt.so /lib/libpthread_rt.so.1
然后， ls -l /lib现在应该显示符号链接和它指向的内容。
我所要做的就是运行：
sudo apt-get install libfontconfig1
我在位于/usr/lib/x86_64-linux-gnu的文件夹中，它工作的很好。
如果您在Microsoft Windows上运行应用程序，则需要在PATH环境variables中定义dynamic库（.dll）的path。
如果您在UNIX上运行应用程序，则需要在LD_LIBRARY_PATH环境variables中定义dynamic库（.so）的path。
尝试安装sudo lib32z1
sudo apt-get install lib32z1
由于系统无法引用提到的库文件，因此发生错误。 采取以下步骤：
-
locate libpthread_rt.so.1它将显示文件的所有位置的列表。这个位置是/home/user/loc。 - 复制位置并回到
home/'user'。 用您想要运行文件的当前活动用户的名称replace“úser”。 -
vi .bash_profile和LD_LIBRARY_PATH参数的末尾.添加行/lib://home/usr/loc:.。 保存文件。 - closuresterminal并重新启动应用程序。 它应该运行。
在Linux x86上使用Eclipse CDT运行我的应用程序时，出现此错误。 要解决这个问题：
- 在Eclipse中：运行方式为>运行configuration>环境
- LD_LIBRARY_PATH = / my_lib_directory_path
