最近在Linux下使用第三方库Protobuf时，遇到一个问题：编译出的可执行程序在运行时总报错：“error while loading shared libraries: libprotobuf.so.7: cannot open shared object file: No such file or directory”。于是花时间弄清楚原因，找到解决方案，跟大家共享一下。
库文件在连接(静态库和共享库)和运行(仅限于使用共享库的程序)时被使用，其搜索路径是在系统中进行设置的。
一般 Linux 系统把 /lib 和 /usr/lib 两个目录作为默认的库搜索路径，所以使用这两个目录中的库时不需要进行设置搜索路径即可直接使用。对于处于默认库搜索路径之外的库，需要将库的位置添加到库的搜索路径之中。设置库文件的搜索路径有下列两种方式，可任选其一使用：
1. 在环境变量 LD_LIBRARY_PATH 中指明库的搜索路径。
例如：export LD_LIBRARY_PATH=/opt/gtk/lib:$LD_LIBRARY_PATH
2. 在/etc/ld.so.conf 文件中添加库的搜索路径（需要root权限）。
将自己可能存放库文件的路径都加入到/etc/ld.so.conf中是明智的选择添加方法也极其简单，将库文件的绝对路径直接写进去就OK了，一行一个。
例如：
/usr/X11R6/lib
/usr/local/lib
/opt/lib
需要注意的是：第二种搜索路径的设置方式对于程序连接时的库(包括共享库和静态库)的定位已经足够了，但是对于使用了共享库的程序的执行还是不够的。这是因为为了加快程序执行时对共享库的定位速度，避免使用搜索路径查找共享库的低效率，所以是直接读取库列表文件 /etc/ld.so.cache 从中进行搜索的。/etc/ld.so.cache 是一个非文本的数据文件，不能直接编辑，它是根据 /etc/ld.so.conf 中设置的搜索路径由 /sbin/ldconfig 命令将这些搜索路径下的共享库文件集中在一起而生成的(ldconfig 命令要以 root 权限执行)。因此，为了保证程序执行时对库的定位，在 /etc/ld.so.conf 中进行了库搜索路径的设置之后，还必须要运行 /sbin/ldconfig 命令更新 /etc/ld.so.cache 文件之后才可以。ldconfig ,简单的说，它的作用就是将/etc/ld.so.conf列出的路径下的库文件缓存到/etc/ld.so.cache 以供使用。因此当安装完一些库文件，(例如刚安装好glib)，或者修改ld.so.conf增加新的库路径后，需要运行一下/sbin/ldconfig使所有的库文件都被缓存到ld.so.cache中，如果没做，即使库文件明明就在/usr/lib下的，也是不会被使用的，结果编译过程中抱错，缺少xxx库，去查看发现明明就在那放着，让人觉得很诡异。
在程序连接时，对于库文件(静态库和共享库)的搜索路径，除了上面的设置方式之外，还可以通过 -L 参数显式指定。因为用 -L 设置的路径将被优先搜索，所以在连接的时候通常都会以这种方式直接指定要连接的库的路径。
第二种设置方式需要 root 权限，以改变 /etc/ld.so.conf 文件并执行 /sbin/ldconfig 命令。而且，当系统重新启动后，所有的基于GTK2的程序在运行时都将使用新安装的GTK+ 库。不幸的是，由于 GTK+ 版本的改变，这有时会给应用程序带来兼容性的问题，造成某些程序运行不正常。为了避免出现上面的这些情况，在 GTK+及其依赖库的安装过程中对于库的搜索路径的设置将采用第一种方式进行。这种设置方式不需要root权限，设置也简单。
因为我是通过终端登陆到服务器上工作的（做自己的private build），没有root权限，所以第一种设置路径的方法自然成了我的选择。我想，对于和我一样在集成环境下工作的同学，使用第一种方法就可以很方便的解决问题。当然，在客户那儿部署最终的Release产品时，可以采用第二种方法。