背景
遇到一个奇葩的项目，有的程序里调的是opencv2.4.13的版本，有的程序里调的是opencv3.2的版本，真实有意思！
程序员天生就是为解决问题而生的！想想该怎么解决吧！因为本人也是接触opencv 不太久，之前接触的用的还是python接口。接下来我将简单的阐述一下我解决这个问题的过程，仅此记录一下这个过程。
解决的想法变化
- 1.想到高版本可能向下兼容。
这是我最初想出来的办法，现在回想起来是多么的蠢。想到这个办法后，我去官网上下载了opencv3.4.5
并对其进行安装，这里简单的说一下opencv的安装过程
1.下载opencv 的源文件
2.确保pc上安装有相关的基础开发包，cmake,g++等
3.cd opencv源码路径
4.新建一个文件夹，用于存放编译好的文件并进入该文件夹中 mdir build && cd build
5.如果没有特殊的需求就直接 cmake ..
6.make && make install
当然对于版本没有要求的话直接可以使用包管理器进行安装
yum install numpy opencv*
安装3.4.5的时候出现了一个错误，说是c++11的问题，应该是g++的问题，多次重现安装并没有解决这个问题，于是在搜索过程中发现opencv 并不能做向下兼容，因为opencv2是相对庞大的，而opencv3则是相对精简的接口之类的都有很大的变化，并且调用opencv的程序编译好之后他只会搜索这个文件，比如libioencv_world.so.2.4，so文件都有对于的版本号。所以说并不是很好处理
- 2.编译多个版本
无奈之下也只能编译2个版本的opencv ，首先把opencv3.2按照上述的方法编译一次，为了省时间，直接从另一台计算机复制处理相关的opencv包，并把该路径加入lib的搜索路径之下，如何加入搜索路径这里稍微说一下
1. 进入 /etc/ld.so.conf.d/
2. 新建一个文件 vi opencv2.4
3. 在文件里编写上lib*的路径比如 /usr/lcoal/opencv2.4
4. 然后ldconfig -v 就可以看到你添加的文件已经到
但是这时候出现另一个奇怪的问题：
/lib64/libc.so.6: version `GLIBC_2.25' not found (required by /lib64/libgnutls.so.30)
通过strings /lib64/libc.so.6 |grep GLIBC_命令看到 机器上的glib的版本是1.7的怪不得不行了，没办法又进入了一次愚蠢的行动中--- 升级glib,从网上找了很多升级的方法，但是每次均以失败告终，为什么会产生这样的结果？通过分析，可以发现这个库是系统非常底层的库，只要提前卸载，或者安装失败都会造成系统不能使用！（辛苦快照多，不然我的类似）在仔细分析，为什么会出现这个问题。因为我复制的别的机器的lib文件，极有可能是因为，编译这个文件的机器版本较高。
- 3.重新编译lib文件
找到问题的关键，只能是自己重新编译一次opencv,并重新把项目中的lib文件也重新编译一次。这下就解决了。
做工程是一件需要认真的事情，通过这次事情又如下几点感受
- 1.团队协作尽量都统一版本，特别是在跨平台的时候，项目中编译版本号都需要写明白。g++的版本，glib的版本，这些影响很大的。
- 2.没做过的事情尽可能的多做调查，以减少踩坑的次数。
- 3.很好用的命令
ldd **可以很快的查出相关的依赖。
网友评论