computing star: Gentoo編譯scipy(with intel MKL)

在gentoo安裝好mkl後，依照官方的說明
http://software.intel.com/en-us/articles/numpyscipy-with-intel-mkl
依序安裝numpy, scipy,
在numpy的部份順利完成，但是在scipy的部份，安裝完後使用
import scipy時，出現

ImportError: /usr/lib64/python2.7/site-packages/scipy/sparse/sparsetools/_csr.so: undefined symbol: __intel_sse4_strlen

原因如下,C/C++ 有完整的「編譯 -> 連結 -> 執行」三個階段, 各階段都可能發生 undefined symbol。在解決惱人的 undefined symbol 前, 得先明白整個編譯流程:

編譯 .c / .cpp 為 .o (object file) 時, 需要提供 header 檔 (用到 gcc 參數 -I)。事實上, 在編譯單一檔案時, gcc/g++ 根本不在意真正的 symbol 是否存在, 反正有宣告它就信了, 所以有引對 header 即可。這也是可分散編譯的原因, 程式之間在編譯成 .o 檔時, 並沒有相依性。
用 linker (ld 或 gold) 將 *.o 連結成 dynamic library 或執行檔時, 需要提供要連結的 library (用到 gcc 參數 -L 指定目錄位置, 用 -l 指定要連什麼函式庫)。不同於前一步, 此時 symbol 一定要在。
執行的時候, 會再動態開啟 shared library 讀出 symbol。換句話說, 前一個步驟只是檢查是否有。檢查通過也連結成 executable 或 shared library 後, 若執行時對應的檔案不見了, 仍會在執行期間找不到 symbol。若位置沒設好, 可能需要用 LIB_LIBRARY_PATH 指定動態函式的位置, 但不建議這麼做, 最好在執行 linker 時就指定好位置。

就看 undefined symbol 發生在那個階段, 若是編 object file 時發生, 就是沒和編譯器說 header 檔在那, 記得用 -I 告訴它。若在 linking 時發生, 就要同時設好 -L 和 -l。不過難就難在要去那找 undefined symbol 的出處。

因為我的問題是發生在執行時間，所以屬於第３類。
首先使用nm _csr.so或是objdump -x _csr.so確認連結。

而 __intel_sse4_strlen定義在
/opt/intel/lib/intel64/libirc.so
/opt/intel/lib/intel64/libiomp5.so

#使用ldconfig -p確認mkl設定（需root權限）
＃ldconfig -p|grep mkl
libiomp5.so (libc6,x86-64) => /opt/intel/composerxe/lib/intel64/libiomp5.so
libirc.so (libc6,x86-64) => /opt/intel/composerxe/lib/intel64/libirc.so

#檢查檔案的格式
$file _csr.so

_csr.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, not stripped

#使用ldd -r查看缺少的symbol
$ldd -r _csr.so

linux-vdso.so.1 => (0x00007fff207ff000)
        libpython2.7.so.1.0 => /usr/lib64/libpython2.7.so.1.0 (0x00007f3757ffe000)
        libstdc++.so.6 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/libstdc++.so.6 (0x00007f3757cf4000)
        libm.so.6 => /lib64/libm.so.6 (0x00007f3757a72000)
        libgcc_s.so.1 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/libgcc_s.so.1 (0x00007f375785c000)
        libc.so.6 => /lib64/libc.so.6 (0x00007f37574d2000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f37572b5000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00007f37570b1000)
        libutil.so.1 => /lib64/libutil.so.1 (0x00007f3756ead000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f37587e8000)
undefined symbol: __intel_sse4_strlen   (./_csr.so)
undefined symbol: _intel_fast_memset    (./_csr.so)
undefined symbol: _intel_fast_memcpy    (./_csr.so)
undefined symbol: __intel_sse4_strncmp (./_csr.so)
undefined symbol: __intel_sse4_strcpy   (./_csr.so)
undefined symbol: __intel_sse4_strncpy (./_csr.so)
undefined symbol: __intel_sse4_strcat   (./_csr.so)

解法方法：
首先在編譯scipy時，使用以下的指令：

python setup.py config --compiler=intelem --fcompiler=intelem build_clib --compiler=intelem --fcompiler=intelem build_ext --compiler=intelem --fcompiler=intelem install >>build.log
將編譯時期的log寫進build.log中
cat build.log|grep _csr.so, 可得到
c++ -shared build/temp.linux-x86_64-2.7/scipy/sparse/sparsetools/csr_wrap.o -L/usr/lib64 -Lbuild/temp.linux-x86_64-2.7 -lpython2.7 -o build/lib.linux-x86_64-2.7/scipy/sparse/sparsetools/_csr.so
copying build/lib.linux-x86_64-2.7/scipy/sparse/sparsetools/_csr.so -> /usr/lib64/python2.7/site-packages/scipy/sparse/sparsetools
由於已知道是linking的時候有問題，所以在scipy目錄下，將上述編譯指令改成：
c++ -shared build/temp.linux-x86_64-2.7/scipy/sparse/sparsetools/csr_wrap.o -L/opt/intel/lib/intel64 -L/usr/lib64 -Lbuild/temp.linux-x86_64-2.7 -lpython2.7 -lirc -o build/lib.linux-x86_64-2.7/scipy/sparse/sparsetools/_csr.so
完成編譯後，將編譯完成的檔案拷貝到系統目錄下(需root權限)
cp build/lib.linux-x86_64-2.7/scipy/sparse/sparsetools/_csr.so /usr/lib64/python2.7/site-packages/scipy/sparse/sparsetools
全部完成後，使用import scipy.sparses(scipy.stats)來確認問題解決。

除了_csr.so之後，還有幾個檔案_csc.so, _coo.so, _dia.so, _bsr.so, _csgraph都是用上述方法解決。

_bsr.so除了-lirc外，還需加上-lsvml.

2013年12月21日

Gentoo編譯scipy(with intel MKL)