gcc制作动态库加载提示“./main: error while loading shared libraries: libcals.so: cannot open shared object fi”

通过gcc制作动态库完成之后，并生成程序的可执行文件之后。若直接运行，会报错“./main: error while loading shared libraries: libcals.so: cannot open shared object file: No such file or directory”。如图所示。

这里先放出动态库加载失败的原因：
静态库和动态库的区别在于，前者GCC进行链接时，会把静态库中代码打包到可执行程序中；后者GCC进行链接时，动态库的代码不会被打包到可执行程序中。
当程序启动之后，动态库会被动态加载到内存中，通过命令$ ldd xxx检查动态库的依赖关系。

到这里就可以知道，因为动态库没有被加载到内存中，所以才导致运行会出错。
注：其中xxx为可执行程序，ldd（list dynamic dependencies）

那么，如何定位共享库文件呢？
当系统加载可执行代码时，能够知道其所依赖的库的名字，但是还需要知道绝对路径。此时就需要系统的动态载入器来获取该绝对路径。
对于elf格式的可执行程序，是由ld-linux.so来完成的，它先后搜索elf文件的DT_RPATH段 ——> 环境变量 LD_LIBRARY_PATH ——> /etc/ld.so.cache文件列表 ——> /lib/或者/usr/lib目录找到库文件后将其载入内存。

解决动态库加载失败问题：
配置其对应的环境变量，使其能找到自己所对应的库文件，命令如下：

$ export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/home/jin/Linux/dynamiclib_test/library/lib
注：后面的路径为动态库存放的路径，可以先cd到对应的文件夹，然后使用命令pwd输出当前的目录

添加环境变量完成以后，在ldd下，发现，找不到的动态库文件可以找到了，如图所示。

此时，我们再执行下这个可执行程序，可以发现，可以正常运行了。

是不是很开心，问题解决了。 然鹅，当你关掉了再打开终端继续运行，你就会发现，又出现和刚才一样的问题了。因为刚刚那个只是临时的，我们需要配置一个永久的环境变量。
这里分为用户级别和系统级别的配置方法，分别如下所示。
1、用户级别配置
step1：进入home目录，命令$ cd ~
step2：$vim .bashrc
step3：shift+g至文件最后 ——》 i ，将环境配置语句添加进去

export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/home/jin/Linux/dynamiclib_test/library/lib

step4：esc ——》：wq！ 保存并退出，$ . ./.bashrc 使之生效。再到指定目录运行即可。

2、系统级别配置
类似于方法一
step1：$ sudo vim /etc/profile
step2：在最后添加环境变量，并保存退出
step3：$. /etc/profile