运行时：
sudo /sbin/ldconfig
出现以下错误：
/sbin/ldconfig: /usr/local/lib/ is not a symbolic link
当我运行file命令时，会出现以下内容：
file /usr/local/lib/
/usr/local/lib/: directory
在/usr/local/lib/中，我使用了三个库。我在这里称它们为lib1、lib2和lib3。
现在，当我对二进制文件执行ldd时，结果是：
lib1.so => not found
lib2.so => not found
lib3.so => /usr/local/lib/lib3.so (0x00216000)
但它们都和/usr/local/lib/{lib1,lib2,lib3}.so在同一个文件夹中。
每次运行ldconfig时，都会出现相同的错误：
/usr/local/lib/ is not a symbolic link
我认为/usr/local/lib应该在/etc/ld.conf.d/*.conf中声明两次，但不是：
sudo egrep '/usr/local' /etc/ld.so.conf.d/*
projectA.conf.old:/usr/local/projectA/lib
local.conf:/usr/local/lib
ld.so.conf只包括/etc/ld.so.conf.d/*.conf，所以不处理这个*.old，它指的是/usr/local/projectA/lib。
经过一段时间的尝试，我删除了所有的lib1和lib2（在某个时候，我在二进制文件的文件夹上测试了它），同样的错误也发生了。
我在Oracle 11R2客户端上遇到了这个问题。不确定是Oracle安装程序做的，还是在我到达之前有人在这里做的。它不是64位对32位，都是64位。
错误是libexpat.so.1不是符号链接。
原来有两个完全相同的文件，libexpat.so.1.5.2和libexpat.so.1。删除有问题的文件并将其作为1.5.2版本的符号链接，导致错误消失。
您希望知名名称成为当前版本的符号链接，这是有道理的。如果你这样做，你就不太可能得到一个过时的库。
我只是运行了下面的命令：
export LD_LIBRARY_PATH=/usr/lib/
现在运行良好。
已解决，至少在问题的关键点。
在询问之前，我在网上搜索了一下，没有最终的解决方案，这个错误的原因是：lib1.so和lib2.so不好，很可能不是为64位PC编译的，而是为32位机器编译的。至少这是我的假设。
非常不幸的是，ldconfig没有给出一个干净的错误消息，通知它无法加载库，它只泵：
ldconfig:/folder_where_the_wicked_lib_is/不是符号链接
当我删除二进制文件上ldd找不到的库时，我解决了这个问题。现在我更容易知道问题出在哪里了。
我的旧版本：GNU ld 2.20.51版本，我不知道最新版本是否对用户有更好的消息。
谢谢。
您需要在/etc/ld.so.conf中包含库的路径，然后重新运行ldconfig以更新列表
另一种可能性是在env变量LD_LIBRARY_PATH中包含库的路径，然后重新运行可执行文件。
如果符号链接指向有效的库，请检查它们。。。
您可以直接在/etc/ld.so.conf中添加路径，而不包括。。。
运行ldconfig -p，查看您的库是否包含在缓存中。
我也遇到过同样的问题，解决方案是：您得到错误的文件可能是另一个版本的实际文件的重复文件。因此，只需删除引发错误的特定文件就可以解决问题。
在shell中简单运行：sudo apt-get-install--重新安装libexpat1
用libxcb得到了同样的问题-以这种方式解决-非常快：）