背景

遇到一个奇葩的项目，有的程序里调的是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 ** 可以很快的查出相关的依赖。