linux下安装包打包依赖库所走的弯路
鉴于之前并没有比较熟练的制作安装包的经验，一直走在摸索的路上，如果看过我之前写过关于制作二进制安装包和rpm安装包的小盆友们，会发现之前写的blog，也是漏洞百出，不慎完美。在这条摸索的路上，公司没有相应经验的师傅，一路走来，走了不少弯路，也给公司实施人员附加了不少工作量（因安装包，原只是在gnome平台上制作的，紧接着又在kde等平台上运行）。其中困惑最近的也就是库冲突问题。下面简单介绍下背景，基本也都是度娘上找到的，如有不同见解可指出，请轻拍，小女子在此谢过！
KDE与GNOME项目拥有相同的目标，就是为Linux开发一套高价值的图形操作环境，两者都采用GPL公约发行，不同之处在于KDE基于双重授权的Qt，而GNOME采用遵循 GPL的GTK库开发—后者拥有更广泛的支持。
以上可知：KDE是基于双重授权的Qt开发的。而公司做的产品也是基于Qt去开发的。我在制作安装包的时候，本着以减少对系统库依赖性以及增强产品健壮性为原则(系统qt库与产品依赖库版本不一致，造成不兼容？系统就没有qt库？这都会导致产品无法启动)，自然将能打包的库全打包了。那么问题来了。怎么添加库搜索路径呢？
鉴于不是纯正的计算机出身，问题来了就找度娘呗。网上提供的最多方法就是1.通过设置系统环境变量LD_LIBRARY_PATH;2.配置文件/etc/ld.so.conf。
linux普遍都是多用户操作，根据用户需求，希望我们的产品支持多用户，那么注册系统环境变量的文件有哪些，怎样才能生效？这个就请大家自行查阅了解。最终我选择了/etc/profile中注册LD_LIBRARY_PATH这条路。。。这个就是后期在产品适配中给我带来最大麻烦的地方。也是备受诟病的地方。。。
与多个KDE操作系统进行适配，总结经验，在KDE上/etc/profile上注册普通的系统环境变量都可以生效，唯独LD_LIBRARY_PATH这个不能生效。我了个去，reader死活起不来。后来从网上了解有些系统LD_LIBRARY_PATH是is ignored。。。还有牛牛推荐阅读why LD_LIBRYRY_PATH is bad这本书，有兴趣的友友可以去看看。那么只能采取第二方案了。在/etc/ld.so.conf.d下增加.conf文件，别忘ldconfig下。公司现有的操作系统大部分是gnome的，一路绿灯啊。心中那个高兴。并且让与公司合作的一个KDE版厂商也帮忙测试，通过。那么这么多系统都通过了，自然大家都采用这个方案了。。。
没过两天，新适配的厂商打电话反馈系统装完软件重启机器起不来？纳尼!!!操作系统反馈KDE是基于Qt开发的，系统启动要加载qt库，而我们的产品追加了动态库搜索路径（qt的），导致系统加载错误的qt库而挂掉？？？我带着各种怀疑，甚至觉得操作系统处理动态库加载的时候不会检测动态库版本吗？就胡乱加载？可是产品再有“理”（不知者不怪，看客轻拍，因为无知，所以到现在还有这个疑惑，还会找机会了解相关内容的），总还是要在人家机器适配呀，人家是老大说不让那样用，那就不能那样用不是。
想破脑袋，灵机一闪，产品本身不也使用第三方动态库吗？不是通过loadlibray做的吗？那为何不可用同样的方法去做呢？指定了g++的编译选项-L编译运行一切ok，窃喜，双击应用程序，不能运行，fuck，又是哪儿有问题，终端跑一下看看，没有找到libQtGui.so.4。我去，不是指定了吗？无奈啊，只能找度娘，后来才了解到链接时库和运行时库的概念，感慨自己虽然平时被同事夸奖已经不错了，但仍是门外汉，也不是纯正的计算机出身，还是有些遗憾的。不过仍旧相信总裁说的，这些都是可以自己学习的。
到此处问题目前在适配的机器上进行测试，都是ok的。。就看后面会不会再出乱子，祈祷。。。
下面给出动态库的搜索路径搜索的先后顺序是：
1.编译目标代码时指定的动态库搜索路径；g++ -Wl,rpath=/opt/testlib
2.环境变量LD_LIBRARY_PATH指定的动态库搜索路径；
3.配置文件/etc/ld.so.conf中指定的动态库搜索路径；
4.默认的动态库搜索路径/lib；
5.默认的动态库搜索路径/usr/lib。
在上述1、2、3指定动态库搜索路径时，都可指定多个动态库搜索路径，其搜索的先后顺序是按指定路径的先后顺序搜索的。
mark一下，好记性不如烂笔头嘛。。。请路过的大侠多多批评给出见解，也请轻拍。
