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

[QiJune]

@tensor-tang 是的，因为矩阵乘法依赖于mklml库

那个相对路径是怎么出来的还在看，但是即使改成绝对路径也不能解决python包的问题。
在安装paddle的python包时，需要把mklml的动态库放置在core.so的同级目录下，并且修改core.so的rpath，让其指定是当前目录

[tensor-tang]

但是即使改成绝对路径也不能解决python包的问题。

这点我就不是很明白了，如果mklml让用户安装的话，还是会有这个问题吗？

[QiJune]

在编译的时候，设置python/paddle/v2/framework/core.so依赖的是一个绝对路径，third_party里面的mklml动态库。这样如果用户自己是编译paddle源代码，然后pip install自己生成的wheel包就不会有问题。

但是，在发布python包的时候，如果不考虑让用户安装mklml，那么就需要把mklml动态库给拷贝到wheel包里面，同时需要把core.so的rpath给设置对了，设置为core.so同一级目录的路径，而不是编译时的third_party的绝对路径。

[tensor-tang]

这样如果用户自己是编译paddle源代码，然后pip install自己生成的wheel就不会有问题。

这点我同意。

但是， 我认为整体上是两个问题，单独来看：

第一个问题，

最后python/addle/v2/framework里面会编译生成一个core.so的动态库，这个动态库会依赖于libmklml_intel.so. 在python包安装之后，路径就不太对

不管是不是用户安装，还是用third party 的mklml。如果在绝对路径对了的情况下，是不是可以解决你上面的问题？如果是，那么我认为你的问题#3209 找不到libmklml的问题就解了， 因为你是ldd出来的结果，如果lib都能found 就没有问题了，对吧。

第二问题，才是 我们到底是应该以怎样的方式使用mklml，这样时候才是发布Python包的问题。
假如不是用户设置，就需要把mklml的包放入whl， 这个时候你才需要考虑改core.so的rpath，让mklml的路径正确。

但是，这个issue的topic是讨论的是第二问题，我觉得不影响你在现有的情况下解决问题一，对吧？

如果我的理解有误，请随时指正我，谢谢。

[QiJune]

@tensor-tang
你理解的很正确，是两个问题。

第一个问题，要保证链接的是绝对路径，似乎现在cmake会自动找相对路径；目前还在尝试解决方案
现在可以先把with_mklml关闭吗，这样暂时不会block其他工作。然后同时我们来找解决方案

[luotao1]

可以先把with_mklml和with_mkldnn都关了。那后面的思路是：如果用户下载了mklml，paddle就来编译mkldnn么？

[tensor-tang]

我认为，可以先单独关闭WITH_MKLML，他不会影响MKLDNN的打开和测试，仅仅是性能上的损失。

[tensor-tang]

hi @QiJune
关于绝对路径的问题，不知道对你的PR#3209有没有帮助，我在最新的code上试了如下的事情：

1. 下载最新的code，commit 为d2e9434636161a73631483ecd80e87d577cb8482

2. diff

diff --git a/paddle/operators/CMakeLists.txt b/paddle/operators/CMakeLists.txt
index b3399aa..02e4dda 100644
--- a/paddle/operators/CMakeLists.txt
+++ b/paddle/operators/CMakeLists.txt
@@ -50,7 +50,7 @@ op_library(add_op SRCS add_op.cc add_op.cu)

 op_library(mean_op SRCS mean_op.cc mean_op.cu)

-op_library(mul_op SRCS mul_op.cc mul_op.cu)
+op_library(mul_op SRCS mul_op.cc mul_op.cu DEPS cblas)
 op_library(rowwise_add_op SRCS rowwise_add_op.cu rowwise_add_op.cc)

 op_library(sigmoid_op SRCS sigmoid_op.cc sigmoid_op.cu)

3. 编译并安装whl后，ldd出来的结果已经是绝对路径了：

ldd /usr/lib/python2.7/site-packages/paddle//v2/framework/core.so
linux-vdso.so.1 => (0x00007fffd6ae9000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fd75b9e3000)
libpython2.7.so.1.0 => /lib64/libpython2.7.so.1.0 (0x00007fd75b617000)
libmklml_intel.so => /home/tangjian/paddle-merge/build/third_party/install/mklml/mklml_lnx_2018.0.20170720/lib/libmklml_intel.so (0x00007f d753af4000)
libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007fd753772000)
libm.so.6 => /lib64/libm.so.6 (0x00007fd75346f000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fd753259000)
libc.so.6 => /lib64/libc.so.6 (0x00007fd752e97000)
/lib64/ld-linux-x86-64.so.2 (0x00007fd75c0e9000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007fd752c92000)
libutil.so.1 => /lib64/libutil.so.1 (0x00007fd752a8f000)

4. 然后我又还了一台机器，这台机器并没有编译过paddle，安装相同的whl包，再ldd，然后才显示找不到lib（因为实际上根本就不存在），并没有出现相对路径。

ldd /usr/lib/python2.7/site-packages/paddle//v2/framework/core.so
linux-vdso.so.1 => (0x00007ffe29fe5000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f3bdca5f000)
libpython2.7.so.1.0 => /lib64/libpython2.7.so.1.0 (0x00007f3bdc693000)
libmklml_intel.so => not found
libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007f3bdc311000)
libm.so.6 => /lib64/libm.so.6 (0x00007f3bdc00e000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f3bdbdf8000)
libc.so.6 => /lib64/libc.so.6 (0x00007f3bdba37000)
/lib64/ld-linux-x86-64.so.2 (0x00007f3bdd168000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f3bdb832000)
libutil.so.1 => /lib64/libutil.so.1 (0x00007f3bdb62f000)

所以我觉得是不是cmake 版本的问题？

我的cmake 版本是3.5.2