Ubuntu的ldconfig详解(解决*.so不是符号连接)

自己在CUDA cudnn这一块出现错误了‘’/sbin/ldconfig.real: /usr/local/cuda-8.0/targets/x86_64-Linux/lib/libcudnn.so.4 不是符号连接‘’

然后在终端输入：

sudo ldconfig -v

找到这一行错误：libcudnn.so.4 -> libcudnn.so.4.0.7

是这个链接错误，然后在终端输入：

 sudo ln -sf /usr/local/cuda-8.0/targets/x86_64-linux/lib/libcudnn.so.4.0.7 /usr/local/cuda-8.0/targets/x86_64-linux/lib/libcudnn.so.4

问题就解决了。。。。。。。。。。。。。

=================================================================================================================

http://stackoverflow.com/questions/43016255/libegl-so-1-is-not-a-symbolic-link

出现的问题

/sbin/ldconfig.real: /usr/lib/nvidia-375/libEGL.so.1 不是符号连接
/sbin/ldconfig.real: /usr/lib32/nvidia-375/libEGL.so.1 不是符号连接

原因：

系统找的是一个符号连接，而不是一个文件。

解决方法：

sudo mv /usr/lib/

nvidia-375/libEGL.so.1 /usr/lib/nvidia-375/libEGL.so.1.org
sudo mv /usr/lib32/nvidia-375/libEGL.so.1 /usr/lib32/nvidia-375/libEGL.so.1.org
sudo ln -s /usr/lib/nvidia-375/libEGL.so.375.39 /usr/lib/nvidia-375/libEGL.so.1
sudo ln -s /usr/lib32/nvidia-375/libEGL.so.375.39 /usr/lib32/nvidia-375/libEGL.so.1

=====================================================================================================

动态链接库管理命令

为了让动态链接库为系统所共享,还需运行动态链接库的管理命令--ldconfig.此执行程序存放在/sbin目录下.

ldconfig命令的用途,主要是在默认搜寻目录(/lib和/usr/lib)以及动态库配置文件/etc/ld.so.conf内所列的目录下,搜索出可共享的动态链接库(格式如前介绍,lib*.so*),进而创建出动态装入程序(ld.so)所需的连接和缓存文件.缓存文件默认为/etc/ld.so.cache,此文件保存已排好序的动态链接库名字列表.

ldconfig通常在系统启动时运行,而当用户安装了一个新的动态链接库时,就需要手工运行这个命令.

ldconfig命令行用法如下:

ldconfig [-v|--verbose] [-n] [-N] [-X] [-f CONF] [-C CACHE] [-r ROOT] [-l] [-p|--print-cache] [-c FORMAT] [--format=FORMAT] [-V] [-?|--help|--usage] path...

ldconfig可用的选项说明如下:

(1) -v或--verbose : 用此选项时,ldconfig将显示正在扫描的目录及搜索到的动态链接库,还有它所创建的连接的名字.

(2) -n : 用此选项时,ldconfig仅扫描命令行指定的目录,不扫描默认目录(/lib,/usr/lib),也不扫描配置文件/etc/ld.so.conf所列的目录.

(3) -N : 此选项指示ldconfig不重建缓存文件(/etc/ld.so.cache).若未用-X选项,ldconfig照常更新文件的连接.

(4) -X : 此选项指示ldconfig不更新文件的连接.若未用-N选项,则缓存文件正常更新.

(5) -f CONF : 此选项指定动态链接库的配置文件为CONF,系统默认为/etc/ld.so.conf.

(6) -C CACHE : 此选项指定生成的缓存文件为CACHE,系统默认的是/etc/ld.so.cache,此文件存放已排好序的可共享的动态链接库的列表.

(7) -r ROOT : 此选项改变应用程序的根目录为ROOT(是调用chroot函数实现的).选择此项时,系统默认的配置文件/etc/ld.so.conf,实际对应的为ROOT/etc/ld.so.conf.如用-r /usr/zzz时,打开配置文件/etc/ld.so.conf时,实际打开的是/usr/zzz/etc/ld.so.conf文件.用此选项,可以大大增加动态链接库管理的灵活性.

(8) -l : 通常情况下,ldconfig搜索动态链接库时将自动建立动态链接库的连接.选择此项时,将进入专家模式,需要手工设置连接.一般用户不用此项.

(9) -p或--print-cache : 此选项指示ldconfig打印出当前缓存文件所保存的所有共享库的名字.

(10) -c FORMAT 或--format=FORMAT : 此选项用于指定缓存文件所使用的格式,共有三种:old(老格式),new(新格式)和compat(兼容格式,此为默认格式).

(11) -V : 此选项打印出ldconfig的版本信息,而后退出.

(12) -? 或--help 或--usage : 这三个选项作用相同,都是让ldconfig打印出其帮助信息,而后退出.

举三个例子:

例1:

# ldconfig -p

793 libs found in cache `/etc/ld.so.cache'

libzvt.so.2 (libc6) =>; /usr/lib/libzvt.so.2

libzvt.so (libc6) =>; /usr/lib/libzvt.so

libz.so.1.1.3 (libc6) =>; /usr/lib/libz.so.1.1.3

libz.so.1 (libc6) =>; /lib/libz.so.1

......

注: 有时候用户想知道系统中有哪些动态链接库,或者想知道系统中有没有某个动态链接库,这时,可用-p选项让ldconfig输出缓存文件中的动态链接库列表,从而查询得到.例子中,ldconfig命令的输出结果第1行表明在缓存文件/etc/ld.so.cache中找到793个共享库,第2行开始便是一系列共享库的名字及其全名(绝对路径).因为实际输出结果太多,为节省篇幅,以......表示省略的部分.

例2:

# ldconfig -v

/lib:

liby.so.1 ->; liby.so.1

libnss_wins.so ->; libnss_wins.so

......

/usr/lib:

libjscript.so.2 ->; libjscript.so.2.0.0

libkspell.so.2 ->; libkspell.so.2.0.0

......

/usr/X11R6/lib:

libmej-0.8.10.so ->; libmej-0.8.10.so

libXaw3d.so.7 ->; libXaw3d.so.7.0

......

注: ldconfig命令在运行正常的情况下,默认不输出什么东西.本例中用了-v选项,以使ldconfig在运行时输出正在扫描的目录及搜索到的共享库,用户可以清楚地看到运行的结果.执行结束后,ldconfig将刷新缓存文件/etc/ld.so.cache.

例3:

# ldconfig /usr/zhsoft/lib

最近新装软件gaim 0.77/ openQ 0.3，需要关联的包有N多，又都是新版的才可以。

=====================================================================================================

其实这个错误归根到底还是共享库的管理：

共享库

在编写程序时，您会依靠其他人已经写好的许多代码来执行例程或特殊功能。这些代码存储在共享库中。要使用它们，需要将它们与您的代码相链接，无论是在构建程序时还是在运行程序时。

前提条件

要从本系列教程中获得最大收获，您应该掌握 Linux 的基本知识，还应该有一个正常工作的 Linux 系统，您可以在这个系统上实践本教程中涵盖的命令。有时候，程序的不同版本将获得不同的输出格式，所以您的结果可能并不总是与这里显示的清单和图完全相同。具体地讲，本教程中的许多示例都来自 64 位系统。我包含了一些来自 32 位系统的示例，以演示它们之间的重要区别。

静态和动态链接

Linux 系统有两种类型的可执行程序：

静态链接可执行程序：包含它们需要执行的所有库函数；所有库函数都链接到可执行程序中。它们是完整的程序，其运行不依赖于外部库。静态链接程序的一个优势是，它们不需要安装必须具备的软件即可运行。
动态链接可执行程序：一些小得多的程序；它们需要来自外部共享库的函数才能运行，因此它们是不完整的。除了更小之外，动态链接还允许程序包指定必须具备的库，而不必将这些库包含在程序包中。通过使用动态链接，许多运行的应用程序可以共享一个库的副本，这样就不会使用相同代码的许多服务来占用内存。出于这些原因，当今大多数程序都采用了动态链接。

在许多 Linux 系统上，有一个有趣的示例，即 ln 命令 (/bin/ln)，它在文件之间创建链接，不论是硬链接还是软（或者符号）链接。该命令使用了共享库。共享库通常涉及库的通用名称与库的特定级别之间的符号链接，所以如果因为某种原因链接没有出现或已断开，那么ln 命令本身可能无法起作用，并会导致一个循环问题。为了防止出现这种可能性，一些 Linux 系统包含了ln 程序的静态链接版本作为sln 程序 (/sbin/sln)。清单 1 演示了动态链接 ln 和静态链接sln 在大小上的巨大差异。该示例来自一个 Fedora 22 64 位系统。

清单 1. sln 和 In 的大小

[ian@atticf20 ~]$ # Fedora 22 64-bit
[ian@atticf20 ~]$ ls -l /sbin/sln /bin/ln
-rwxr-xr-x.1 root root  58656 May 14 04:56 /bin/ln
-rwxr-xr-x.1 root root 762872 Feb 23 10:36 /sbin/sln

需要哪些库？

尽管当前的 LPI 考试不要求了解这个主题，但您应该知道，当今许多 Linux 系统都允许在同时支持 32 位和 64 位可执行程序的硬件上运行。因此，许多库被编译为 32 位和 64 位版本。64 位版本通常存储在文件系统的 /lib64 树下，而 32 位版本位于传统的 /lib 树下。在典型的 64 位 Linux 系统上，您可能会同时找到 /lib/libc-2.11.1.so 和 /lib64/libc-2.11.1.so。这两个库允许 32 位和 64 位 C 程序在 64 位 Linux 系统上运行。

`ldd` 命令

除了知道静态链接程序可能很大之外，您如何确定程序是否为静态链接？如果它是动态链接的，您如何知道它需要哪些库？ldd 命令可以回答这两个问题。如果运行 Debian 或 Ubuntu 等系统，您可能找不到 sln 可执行程序，因此您可能想要检查 /sbin/ldconfig 可执行程序。清单 2显示了 ln 和 sln 可执行程序以及 ldconfig 可执行程序的ldd 命令的输出。该示例来自一个 Fedora 22 64 位系统 (atticf20)。为了进行比较，我们显示了 Ubuntu 14 32 位系统 (attic-u14) 对于 /bin/ln 的输出。

清单 2. sln 和 In 的 `ldd` 命令的输出

[ian@atticf20 ~]$ # Fedora 22 64-bit
[ian@atticf20 ~]$ ldd /sbin/sln /sbin/ldconfig /bin/ln
/sbin/sln:not a dynamic executable
/sbin/ldconfig:not a dynamic executable
/bin/ln:linux-vdso.so.1 (0x00007ffedd31e000)libc.so.6 => /lib64/libc.so.6 (0x00007f2d3bd5d000)/lib64/ld-linux-x86-64.so.2 (0x00007f2d3c11d000)ian@attic-u14:~/data/lpic-1$ # Ubuntu 14 32-bit
ian@attic-u14:~/data/lpic-1$ ldd /bin/lnlinux-gate.so.1 =>  (0xb779d000)libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb75d7000)/lib/ld-linux.so.2 (0xb77a0000)

因为 ldd 实际上与动态链接有关，这告诉我们 sln 和 ldconfig 都是静态链接的，它们“不是一个动态可执行程序”，同时告诉我们ln 命令所需的三个共享库的名称（linux-vdso.so.1、libc.so.6 和 /lib64/ld-linux-x86-64.so.2）。请注意，.so 表明这些是共享对象 或动态库。此输出还演示了您可能想了解的三种不同类型的信息。

linux-vdso.so.1

是 Linux 虚拟动态共享对象，我们稍后将讨论它。您还可以像在 Ubuntu 14 示例中一样看到 linux-gate.so.1。

libc.so.6

有一个指向 /lib64/libc.so.6 或 /lib/i386-linux-gnu/libc.so.6 的指针。您还可以看到，该指针指向旧版 32 位系统上的 /lib/libc.so.6。

/lib64/ld-linux-x86-64.so.2

是另一个库的绝对路径。

在清单 3 中，我使用了 ls -l 命令来依次显示最后两个库，它们是这些库的特定版本的动态链接。该示例来自一个 Fedora 22 64 位系统。这使得在安装库更新时，无需重新链接使用该库的可执行程序。

清单 3. 库符号链接

[ian@atticf20 ~]$ # Fedora 22 64-bit
[ian@atticf20 ~]$ ls -l /lib64/libc.so.6 /lib64/ld-linux-x86-64.so.2
lrwxrwxrwx.1 root root 10 Feb 23 10:33 /lib64/ld-linux-x86-64.so.2 -> ld-2.21.so
lrwxrwxrwx.1 root root 12 Feb 23 10:33 /lib64/libc.so.6 -> libc-2.21.so

Linux 虚拟动态共享对象

在 x86 处理器发展的早期，用户程序与管理服务之间的通信是通过软件中断来实现的。随着处理器速度的提高，这已成为一个严重的瓶颈。自 Pentium® II 处理器开始，Intel ®引入了一个Fast System Call 装置来提高系统调用速度，使用 SYSENTER 和 SYSEXIT 指令而不是中断来提高速度。

您看到的库 linux-vdso.so.1 是一个虚拟库，或者说是虚拟动态共享对象，它只位于每个程序的地址空间中。一些系统将它称为 linux-gate.so.1。这个虚拟库提供了必要的逻辑，允许用户程序通过特殊处理器上可用的更快方法来访问系统函数，无论该方法是中断还是大多数较新的处理器中采用的快速系统调用。

动态加载

通过前面的内容，您可能会惊奇地发现 /lib/ld-linux.so.2 和它的 64 位版本 /lib64/ld-linux-x86-64.so.2（看上去都像是共享库）实际上是都是独立的可执行程序。它们是负责动态加载的代码。它们读取可执行程序的标头信息，该信息为 Executable and Linking Format (ELF) 格式。它们根据此信息确定需要哪些库，以及需要加载哪些库。然后执行动态链接来安排好可执行程序和已加载的库中的所有地址指针，让程序能够运行。

ld-linux.so 的手册页也描述了 ld.so，后者为早期的 a.out 二进制格式执行了类似的功能。清单 4演示了使用 ld-linux.so 的--list 选项来显示与清单 2ldd 命令中显示的信息相同的ln 命令的信息。

清单 4. 使用 ld-linux.so 显示库需求

[ian@atticf20 ~]$ # Fedora 22 64-bit
[ian@atticf20 ~]$ /lib64/ld-linux-x86-64.so.2 --list /bin/lnlinux-vdso.so.1 (0x00007ffe725f6000)libc.so.6 => /lib64/libc.so.6 (0x00007f2179b5d000)/lib64/ld-linux-x86-64.so.2 (0x00007f2179f1d000)ian@attic-u14:~$ # Ubuntu 14 32-bit
ian@attic-u14:~$ /lib/ld-linux.so.2 --list /bin/lnlinux-gate.so.1 =>  (0xb77bc000)libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb75f6000)/lib/ld-linux.so.2 (0xb77bf000)

请注意，两个清单中的十六进制地址可能有所不同。如果运行 ldd 两次，它们可能也是不同的。

动态库配置

那么动态加载程序如何知道从何处查找可执行程序？对于 Linux 上的许多问题，/etc 中都有一个配置文件。事实上，有两个配置文件：/etc/ld.so.conf 和 /etc/ld.so.cache。清单 5显示了 64 位 Fedora 22 系统上的 /etc/ld.so.conf 的内容。请注意，/etc/ld.so.conf 指定所有来自子目录 ld.so.conf.d 的 .conf 文件都应被包含。旧版系统可能拥有 /etc/ld.so.conf 中的所有条目，而不包含来自 /etc/ld.so.conf.d 目录的条目。在您的系统上，/etc/ld.so.conf 或 /etc/ld.so.conf.d 目录的实际内容可能有所不同。

清单 5. /etc/ld.so.conf 的内容

[ian@atticf20 ~]$ # Fedora 22 64-bit
[ian@atticf20 ~]$ cat /etc/ld.so.conf
include ld.so.conf.d/*.conf
[ian@atticf20 ~]$ ls /etc/ld.so.conf.d/*.conf
/etc/ld.so.conf.d/atlas-x86_64.conf
/etc/ld.so.conf.d/bind99-x86_64.conf
/etc/ld.so.conf.d/kernel-4.0.4-301.fc22.x86_64.conf
/etc/ld.so.conf.d/kernel-4.0.4-303.fc22.x86_64.conf
/etc/ld.so.conf.d/kernel-4.0.6-300.fc22.x86_64.conf
/etc/ld.so.conf.d/libiscsi-x86_64.conf
/etc/ld.so.conf.d/llvm-x86_64.conf
/etc/ld.so.conf.d/mariadb-x86_64.conf

程序加载必须很快，因此可以使用 ldconfig 命令来处理 ld.so.conf 文件、ld.so.conf.d 中包含的所有文件、受信任的目录中的库、/lib 和 /usr/lib，以及命令行上受支持的其他所有内容。ldconfig 命令在 /etc/ld.so.cache 中为最近使用的共享库创建了必要的链接和缓存。动态加载程序使用来自 ld.so.cache 的缓存信息来加载要动态加载和链接的文件。如果更改 ld.so.conf（或将新包含的文件添加到 ld.so.conf.d 中），则必须（以根用户身份）运行 ldconfig 命令来重新构建 ld.so.cache 文件。

通常，在不用参数的情况下使用 ldconfig 命令来重新构建 ld.so.cache。还可以指定其他一些参数来覆盖这种默认行为。一般情况下，可以尝试使用 man ldconfig 获取更多的信息。清单 6 演示了使用 -p 参数来显示 ld.so.cache 的内容。

清单 6. 使用 ldconfig 显示 ld.so.cache

[ian@atticf20 ~]$ # Fedora 22 64-bit
[ian@atticf20 ~]$ /sbin/ldconfig -p | less
1361 libs found in cache `/etc/ld.so.cache'p11-kit-trust.so (libc6,x86-64) => /lib64/p11-kit-trust.solibzeitgeist-2.0.so.0 (libc6,x86-64) => /lib64/libzeitgeist-2.0.so.0libzapojit-0.0.so.0 (libc6,x86-64) => /lib64/libzapojit-0.0.so.0libz.so.1 (libc6,x86-64) => /lib64/libz.so.1libyelp.so.0 (libc6,x86-64) => /lib64/libyelp.so.0libyaml-0.so.2 (libc6,x86-64) => /lib64/libyaml-0.so.2libyajl.so.2 (libc6,x86-64) => /lib64/libyajl.so.2libxtables.so.10 (libc6,x86-64) => /lib64/libxtables.so.10libxslt.so.1 (libc6,x86-64) => /lib64/libxslt.so.1libxshmfence.so.1 (libc6,x86-64) => /lib64/libxshmfence.so.1libxml2.so.2 (libc6,x86-64) => /lib64/libxml2.so.2libxmlrpc_util.so.3 (libc6,x86-64) => /lib64/libxmlrpc_util.so.3libxmlrpc_server_cgi.so.3 (libc6,x86-64) => /lib64/libxmlrpc_server_cgi.so.3libxmlrpc_server_abyss.so.3 (libc6,x86-64) => /lib64/libxmlrpc_server_abyss.so.3libxmlrpc_server.so.3 (libc6,x86-64) => /lib64/libxmlrpc_server.so.3libxmlrpc_client.so.3 (libc6,x86-64) => /lib64/libxmlrpc_client.so.3libxmlrpc_abyss.so.3 (libc6,x86-64) => /lib64/libxmlrpc_abyss.so.3libxmlrpc.so.3 (libc6,x86-64) => /lib64/libxmlrpc.so.3libxml-security-c.so.16 (libc6,x86-64) => /lib64/libxml-security-c.so.16libxlutil.so.4.3 (libc6,x86-64) => /lib64/libxlutil.so.4.3libxklavier.so.16 (libc6,x86-64) => /lib64/libxklavier.so.16libxkbfile.so.1 (libc6,x86-64) => /lib64/libxkbfile.so.1
:

加载特定的库

如果正在运行需要一个特定旧版共享库的旧版应用程序，或者正在开发新的共享库或一个共享库的新版本，您可能希望覆盖加载程序使用的默认搜索路径。使用可能安装在 /opt 树中的特定于产品的共享库的脚本可能也需要这一功能。

就像可以设置 PATH 变量来为可执行程序指定搜索路径一样，可以将 LD_LIBRARY_PATH 变量设置为一个以冒号分隔的目录列表，应该首先在这个列表中搜索共享库，然后再在 ld.so.cache 中指定的系统目录中进行搜索。例如，您可以使用一个类似下面命令的命令：

export LD_LIBRARY_PATH=/usr/lib/oldstuff:/opt/IBM/AgentController/lib

不错的学习链接：

http://www.aichengxu.com/view/1370151

http://www.ibm.com/developerworks/cn/linux/l-lpic1-102-3/index.html

http://www.cnitblog.com/yunshichen/archive/2009/08/28/61065.html

http://www.cnblogs.com/cnhome/archive/2009/10/11/1580911.html