refine the dependencies of BLAS related libraries

[QiJune]

目前paddle处理blas相关的依赖库如下：

分支A：
1默认安装 MKLML WITH_MKLML=ON

2 下载 mklml库 include(external/mklml)

3 检查机器上是否存在blas库 include(externel/openblas) —> include(cblas)
因为已经下载安装mklml库，所以检查成功

分支B：
1 如果关闭MKLML库 WITH_MKLML=OFF

2 跳过下载mklml库

3 检查机器上是否存在blas库 include(externel/openblas) —> include(cblas)

4 依次搜索MKL/ATLAS/OpenBLAS等库，用户可以设置MKL_ROOT/ATLAS_ROOT/OPENBLAS_ROOT等指定路径；如果找到，会加上相应的编译选项，例如add_definitions(-DPADDLE_USE_OPENBLAS)

5 如果上述库都没有找到，则进入下载编译openblas阶段， 在这里会触发一个bug，没有设置
add_definitions(-DPADDLE_USE_OPENBLAS)

目前遇到一个问题是，如果打开WITH_MKLML选项，则mklml相关动态库会被安装在third_party目录下，安装python wheel包之后，目前的在python/paddle/v2/framework的core.so会找不到相应的mklml动态库

对于blas相关的库依赖有两种解决方案：
方案一：让用户安装相应的库，然后指定相应的路径传给paddle；
方案二：使用third_party的方式来下载依赖

目前两种都支持，但是存在互相交叉，python端的动态库依赖还没有解决。
使用方案一会使得依赖问题会清爽一些，依赖问题也容易解决

[tensor-tang]

我有几点comment， 仅供大家参考哈：

1. 如果用户自己下载MKLML， 那么我们需要弄个doc提供参考的下载地址，目前最官方的在MKLDNN的github上，会不会让用户confuse？然后还需要用户设置一个环境变量。

2. 如果我们自己把MKLML加入whl，又会有安装包太大的问题，目前MKLML的lib大小为126M。

3. MKLML与MKLDNN都是动态库，现在cblas遇到这个问题是因为MKLML，那么以后估计也会遇到MKLDNN动态库的问题。所以把MKDNN加入whl？好在他的lib在3M左右。

另外，不是很推荐让用户自己下载编译安装MKLDNN，所以最终，至少我们还是要把MKLDNN的lib加入whl，那么还是需要去fix动态库的问题？MKLML的动态库应该也是一回事。

所以最终还是取决大家看觉得怎么最合适？

[luotao1]

如果用户自己下载MKLML， 那么我们需要弄个doc提供参考的下载地址。目前最官方的在MKLDNN的github上，会不会让用户confuse。

MKLML的下载地址是prepare.sh，但这个地址里使用的是mklml_lnx_2018.0.20170425.tgz。Paddle目前使用的是mklml_lnx_2018.0.20170720.tgz。虽然MKLDNN的是最官方的，但我们提供的是最新的，用户应该不会觉得confuse。

需要用户设置一个环境变量

cudnn/nnpack都是让用户设置一个环境变量的。

另外，不是很推荐让用户自己下载编译安装MKLDNN

因为MKLDNN的编译安装略显麻烦，而且mkldnn.lib只有3M，所以可以让用户下载MKLML的lib。MKLDNN的编译安装由Paddle自动完成。

[tensor-tang]

MKLML的下载地址是prepare.sh，但这个地址里使用的是mklml_lnx_2018.0.20170425.tgz

是的，这个应该是还没更新。但是Paddle目前我用的最新的。

那个confuse，其实我想说的用户去下载MKLML却要去MKLDNN的release package里面下，这两个其实应该是独立的关系的，这里会不会有confuse。如果觉得还好的话，应该也没太大关系，比较都是Intel的东西。

[luotao1]

如果采用下载MKLML的方式，就不会让用户去MKLDNN的release package里面下载。这个脚本可以放在Paddle里面。

另外，我们可以先通过修改MKLDNN的源码，让它编译出静态库么？

[QiJune]

@tensor-tang 是的，动态库依赖始终是一个问题，所以可能还是把动态库放到python wheel包里面比较合适

那么，现在需要解决的就是保证python wheel包里面的core.so 依赖于 mklml.so 的依赖路径是对的

[tensor-tang]

@QiJune 关于这个问题，现在他的依赖路径不对吗，我记得以前路径是对的，只不过由于lib被删了，所以才找不到的。
可以给我一个复现的方法吗？

[tensor-tang]

@luotao1

另外，我们可以先通过修改MKLDNN的源码，让它编译出静态库么？

这一点我觉得，我们可以先提一个issue给MKLDNN team， 看他们觉得从mkldnn的角度这样是否可行，有没有别的什么问题，我觉得需要他们先确定。然后我们再改code才有效。他们team的效率还是蛮高的

[QiJune]

@tensor-tang 主要在paddle重构的新代码里面，mul_op是依赖于mklml库的。最后python/paddle/v2/framework里面会编译生成一个core.so的动态库，这个动态库会依赖于libmklml_intel.so. 在python包安装之后，路径就不太对

复现方法如下：

git clone https://github.com/QiJune/Paddle.git paddle
cd paddle
git checkout -b port_blas origin/port_blas
mkdir build
cd build
cmake ..
make -j8
make install
pushd /usr/local/opt/paddle/share/wheels
pip install paddle*.whl
pip install py_paddle*.whl
popd
ctest -V -R test_mul_op

会报这个错误

 import paddle.v2.framework.core as core
 ImportError: ../../third_party/install/mklml/mklml_lnx_2018.0.20170720/lib/libmklml_intel.so: cannot open shared object file: No such file or directory

可以查看安装的paddle包的内容

pushd /usr/local/lib/python2.7/dist-packages/paddle/v2/framework
ldd core.so

会打印如下信息

linux-vdso.so.1 =>  (0x00007ffd21d3f000)
libpython2.7.so.1.0 => /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0 (0x00007f360ac06000)
../../third_party/install/mklml/mklml_lnx_2018.0.20170720/lib/libmklml_intel.so => not found
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f360a9e8000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f360a7e4000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f360a5db000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f360a259000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f3609f50000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f3609d39000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f360996f000)
/lib64/ld-linux-x86-64.so.2 (0x0000564442830000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f3609755000)
libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x00007f3609551000)

也可以先看看#3209 这个pr所产生的build log
https://paddleci.ngrok.io/viewLog.html?buildId=4836&buildTypeId=Paddle_PrCi&tab=buildLog

[tensor-tang]

Thanks @QiJune .

我在最新的paddle上打开MKLML没有发现问题。

ldd core.so
linux-vdso.so.1 => (0x00007ffcb9ff4000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f63fc96d000)
libpython2.7.so.1.0 => /lib64/libpython2.7.so.1.0 (0x00007f63fc5a1000)
libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007f63fc21f000)
libm.so.6 => /lib64/libm.so.6 (0x00007f63fbf1d000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f63fbd06000)
libc.so.6 => /lib64/libc.so.6 (0x00007f63fb944000)
/lib64/ld-linux-x86-64.so.2 (0x00007f63fd06b000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f63fb740000)
libutil.so.1 => /lib64/libutil.so.1 (0x00007f63fb53c000)

没有发现link MKLML的相关信息。

mul_op是依赖于mklml库的

这一点是在你的code里面加的吗？是这里对吗

另外，我看到这个是相对路径

../../third_party/install/mklml/mklml_lnx_2018.0.20170720/lib/libmklml_intel.so => not found

是不是在你code哪里的路径改为绝对路径就好了，实际上lib的存在位置是对的。

并且我检查了下cmake的输出，是绝对路径，所以是不是看下那个相对路径是怎么的出来比较好？

BLAS library: /home/tangjian/paddle-merge/build/third_party/install/mklml/mklml_lnx_2018.0.20170720/lib/libmklml_intel.so