【GCC编译运行报错】error while loading

运行编译后的程序报错  error while loading shared libraries: lib*.so: cannot open shared object file: No such file or directory

-------------------------------------------------------------------------------------------------------------------

　　首先说明一下，这个题目有点长，但是却很好地反应了遇到的问题点。

　　在《如何用C代码生成二维码》一文中，小编也向大家展示了在正确无误地编译好qrcode_test程序后，运行报错的问题。这次我们再拿出来说一说。

当时在终端手动./运行程序报错的提示 ./qrcode_test: error while loading shared libraries: libzint.so.2.4: cannot open shared object file: No such file or directory

 

 

　　大概的意思就是在运行程序的时候，没有找到程序所需的libzint.so动态库。大家都知道，动态库与静态库的最大区别就是：静态库是静态链接，也就是在生产可执行文件的时候就把静态库中的实现嵌入到程序中了，一旦编译成功了，静态库也就有存在的价值了，即便静态库不存在了，可执行程序也是可以跑起来的；但是动态库就不一样了，它是遵循动态链接，也是就说编译的时候需要指定路径去找该so文件链接编译，运行的时候也需要指定相应的路径去找。如果在运行的时候，可执行程序会先去默认的系统lib目录下，寻找该so，如果找不到了，就该报错了：error while loading shared libraries。（可以通过该文章，了解下动态库的动态加载机制 http://blog.csdn.net/dbzhang800/article/details/6918413）

　　上面这一段话，讲可执行程序运行时去找so文件，讲得比较笼统，以下总结以下：

　　动态库的搜索路径搜索的先后顺序是： 

　　1.编译目标代码时指定的动态库搜索路径;

　　2.环境变量LD_LIBRARY_PATH指定的动态库搜索路径； 

　　3.配置文件/etc/ld.so.conf中指定的动态库搜索路径；

　　4.默认的动态库搜索路径/lib    /usr/lib。

　　可参考下这篇博文，它里面提及了gcc编译动态库和运行链接动态库的知识。linux-gcc 编译时头文件和库文件搜索路径 - zhengmeifu - 博客园

　　回到可执行程序运行报error while loading shared libraries错的问题上来，在《如何用C代码生成二维码》一文中，也讲到了如何避过这种错误而将程序跑起来，我们使用的是上面提及的“2.环境变量LD_LIBRARY_PATH指定的动态库搜索路径；”，即通过设置LD_LIBRARY_PATH，把当前程序使用的so的路径添加到LD_LIBRARY_PATH中去，这样程序跑起来的时候，去LD_LIBRARY_PATH找肯定就可以找到该so了。当然之前我们也已经验证了此方法的正确性。

 　　

 

　　看，程序运行就没有问题。

　　如果仅仅又是重复介绍该方法，那么此文存在的意义就不大了。此文最大的意义在于，告诉读者，我们可以不用设置LD_LIBRARY_PAT，也一样可以把程序跑起来，那么我们该从那里下手呢？本文主要介绍，从编译该程序开始。

这里就要先介绍下gcc的编译选项了，但这里不具体细说，有兴趣可以通过man gcc去了解，或者从博文的上一篇文章  【转载】gcc 使用中常用的参数及命令【转载】gcc 使用中常用的参数及命令 - 架构师李肯 - 博客园 去了解。

　　这里，我们需要用到的编译选项是-Wl,-rpath;主要这里是字母l，而不是数字1。-rpath选项就是告诉gcc在编译链接的时候，把该程序的运行是查找so的路径写入到ELF文件中。使用方法就是 gcc –o OutApp *.c –lzint –Wl,-rpath=”/usr/local/lib”或gcc –o OutApp *.c –lzint –Wl,-rpath –Wl,“/usr/local/lib”两者在功能是等价的。如下图所示：

 　　

 

　　从图中我们可看到，确实编译成功后直接运行程序就不会再报error while loading shared libraries了，而且这种方法最大的好处就是，在编译成功后，不用再去做任何设置就可以把程序跑起来了，当然是编译时传递的-rpath参数得是正确的。这个方法，尤其是在交叉编译嵌入式设备的可执行程序时，十分有用。不妨读者可以自己试试看。

​　　审核编辑：汤梓红