topic I totally removed from my in Intel® oneAPI Math Kernel Library

Build R with Intel MKL shared library

arnaud_g_1 — Fri, 18 Sep 2015 11:26:30 GMT

I build sucessfully R 3.2.2 with Intel MKL and ICC. Now I am wondering if library linking are indeed correct. Here is the output:

% R CMD ldd BUILD/R-3.2.2/bin/exec/R
	linux-vdso.so.1 (0x00007ffdbddba000)
	libR.so => /usr/lib64/R/lib/libR.so (0x00007fc76f767000)
	libRblas.so => not found
	libm.so.6 => /lib64/libm.so.6 (0x00007fc76f452000)
	libiomp5.so => /opt/intel/compilers_and_libraries_2016.0.109/linux/compiler/lib/intel64_lin/libiomp5.so (0x00007fc76f111000)
	libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fc76eef9000)
	libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fc76ecdd000)
	libc.so.6 => /lib64/libc.so.6 (0x00007fc76e91d000)
	libdl.so.2 => /lib64/libdl.so.2 (0x00007fc76e718000)
	libblas.so.3 => /lib64/libblas.so.3 (0x00007fc76c674000)
	libgfortran.so.3 => /lib64/libgfortran.so.3 (0x00007fc76c349000)
	libquadmath.so.0 => /lib64/libquadmath.so.0 (0x00007fc76c109000)
	libreadline.so.6 => /lib64/libreadline.so.6 (0x00007fc76bebf000)
	libtre.so.5 => /lib64/libtre.so.5 (0x00007fc76bcaf000)
	libpcre.so.1 => /lib64/libpcre.so.1 (0x00007fc76ba3e000)
	liblzma.so.5 => /lib64/liblzma.so.5 (0x00007fc76b818000)
	libbz2.so.1 => /lib64/libbz2.so.1 (0x00007fc76b608000)
	libz.so.1 => /lib64/libz.so.1 (0x00007fc76b3f1000)
	librt.so.1 => /lib64/librt.so.1 (0x00007fc76b1e9000)
	libicuuc.so.54 => /lib64/libicuuc.so.54 (0x00007fc76ae58000)
	libicui18n.so.54 => /lib64/libicui18n.so.54 (0x00007fc76aa00000)
	libgomp.so.1 => /lib64/libgomp.so.1 (0x00007fc76a7de000)
	/lib64/ld-linux-x86-64.so.2 (0x000055986b173000)
	libtinfo.so.5 => /lib64/libtinfo.so.5 (0x00007fc76a5b3000)
	libicudata.so.54 => /lib64/libicudata.so.54 (0x00007fc768b88000)
	libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007fc768806000)

As you can see, libblas.so.3 is linked to /lib64/libblas.so.3 (0x00007fc76c674000), the library installed on my system. I was expecting something like this (the output comes from another machine with an already built package for R with MKL installed)

libmkl_gf_lp64.so => /opt/intel/mkl/lib/intel64/libmkl_gf_lp64.so (0x00007f3bdfef9000)
libmkl_core.so => /opt/intel/mkl/lib/intel64/libmkl_core.so (0x00007f3bde38c000)
libmkl_gnu_thread.so => /opt/intel/mkl/lib/intel64/libmkl_gnu_thread.so (0x00007f3bdd635000)

Here is part of my package build configuration:

%global _omp_lib /opt/intel/lib/intel64
%global _mkllibs " -fopenmp -wl,--no-as-needed -L%{_mkllibpath} -L%{_omp_lib} -lmkl_intel_ilp64 -lmkl_core -lmkl_intel _intel_thread -liomp5 -lpthread"
%global _mklroot /opt/intel/compilers_and_libraries_2016.0.109/linux/mkl


# Not sure it is needed as all libs are defined in ld.so.conf.d/
source /opt/intel/bin/compilervars.sh intel64 
source /opt/intel/bin/ifortvars.sh intel64

export CC="icc -std=c99"
export F77="ifort"
export CXX="icpc"
export FC="ifort"
export AR="xiar"
export LD="xild"

export CFLAGS="-ip -ipo -opt-mem-layout-trans=3 -xHost -mavx -fp-model precise -wd188 -DMKL_ILP64 -qopenmp -parallel -I%{_mklroot}/include"

%configure \
.......
         --with-blas=%{_mkllibs} \
         --with-lapack \
         --enable-R-shlib \
         --enable-memory-profiling \
         --enable-BLAS-shlib \
................

What am I doing wrong (if doing wrong) and why this liblas.so.3 in my ldd output? Why no libmkl_* => /opt/intel/...

I have tried various settings, with always same result.

Thank you for help

Hi Arnaud,

Ying_H_Intel — Mon, 21 Sep 2015 01:59:08 GMT

Hi Arnaud,

We had build early R version as the two articles

1. https://software.intel.com/en-us/articles/using-intel-mkl-with-r

2. https://software.intel.com/en-us/articles/build-r-301-with-intel-c-compiler-and-intel-mkl-on-linux

I guess, you have read them. Not sure if the build process was changed in later R version.

for example, there are several places;

1. like MKL library mkl_intel_lp64 if with intel compiler ( not mkl_gf_lp64)

If you are building R with Intel C/C++ Compiler icc and Intel Fortran Compiler, then please use

iew source

			
						01
						source /opt/intel/composer_xe_2015.1.133/mkl/bin/mklvars.sh intel64
					
						02
						 
						03
						MKL="   -Wl,--no-as-needed   -Wl,--start-group \
					
						04
						 
						05
						          -lmkl_intel_lp64       \
					
						06
						 
						07
						          -lmkl_intel_thread    \
					
						08
						 
						09
						          -lmkl_core          \
					
						10
						 
						11
						      -Wl,--end-group                           \
					
						12
						 
						13
						      -liomp5 -lpthread  -lm"
					
						14
						 
						15
						    ./configure --with-blas="$MKL" --with-lapack

Check the config.log to see if MKL was working,

configure:29075: checking for dgemm_ in -L/opt/intel/composer_xe_2015.1.133/mkl/lib/intel64/ -lmkl_gf_lp64 -lmkl_sequential -lmkl_core
configure:29096: gcc -std=gnu99 -o conftest -g -O2 -I/usr/local/include -L/usr/local/lib64 conftest.c -L/opt/intel/composer_xe_2015.1.133/mkl/lib/intel64/ -lmkl_gf_lp64 -lmkl_sequential -lmkl_core -lgfortran -lm -lrt -ldl -lm >&5
conftest.c: In function 'main':
conftest.c:210: warning: implicit declaration of function 'dgemm_'
configure:29096: $? = 0
configure:29103: result: yes

3. Could you please try again with simply build command and see if any changes.

I suppose you have intel fortran compiler, intel C compiler and Intel MKL installed in /opt/intel/.

04

05

	
				06
				# Not sure it is needed as all libs are defined in ld.so.conf.d/

	
				07
				source /opt/intel/bin/compilervars.sh intel64

09

	
				10
				export CC="icc -std=c99"

	
				11
				export F77="ifort"

	
				12
				export CXX="icpc"

	
				13
				export FC="ifort"

	
				14
				export AR="xiar"

	
				15
				export LD="xild"

16

17

	
				18
				
									MKL="   -Wl,--no-as-needed   -Wl,--start-group \
								
									04
									 
									05
									          -lmkl_intel_lp64       \
								
									06
									 
									07
									          -lmkl_intel_thread    \
								
									08
									 
									09
									          -lmkl_core          \
								
									10
									 
									11
									      -Wl,--end-group                           \
								
									12
									 
									13
									      -liomp5 -lpthread  -lm"
								
									14
									 
									15
									    ./configure --with-blas="$MKL" --with-lapack

Best Regards,

Ying

source /opt/intel/bin

arnaud_g_1 — Mon, 21 Sep 2015 09:05:00 GMT

source /opt/intel/bin/compilervars.sh intel64

%global _icclibpath ${MKLROOT}/lib/intel64/
%global _mkllibpath /opt/intel/mkl/lib/intel64/

LDFLAGS="$LDFLAGS -L%{_icclibpath} -openmp"
export CC="icc -std=c99"
export F77="ifort"
export CXX="icpc"
export FC="ifort"
export AR="xiar"
export LD="xild"
MKL="  -L%{_mkllibpath} -Wl,--no-as-needed -Wl,--start-group \
    -lmkl_intel_lp64 \
    -lmkl_intel_thread \
    -lmkl_core \
    -Wl,--end-group \
    -liomp5 -lpthread -lm"

export CFLAGS="-ipo -opt-mem-layout-trans=3 -xHost -mavx -fp-model precise -wd188 -DMKL_ILP64 -qopenmp -parallel -I${MKLROOT}/include"
export CXXFLAGS="-ipo -opt-mem-layout-trans=3 -xHost -mavx -fp-model precise -wd188 -DMKL_ILP64 -qopenmp -parallel -I${MKLROOT}/include"
export FFLAGS="-ipo -opt-mem-layout-trans=3 -xHost -mavx -fp-model precise -DMKL_ILP64 -qopenmp -parallel -I$}MKLROOT}/include"
export FCFLAGS="-ipo -opt-mem-layout-trans=3 -xHost -mavx -fp-model precise -DMKL_ILP64 -qopenmp -parall -I${MKLROOT}/include"

%configure \
         --with-system-tre \
         --with-system-zlib --with-system-bzlib --with-system-pcre \
         --with-system-valgrind-headers \
         --with-blas="$MKL" \
         --with-lapack \
         --without-x \
         --with-tcl-config=%{_libdir}/tclConfig.sh \
         --with-tk-config=%{_libdir}/tkConfig.sh \
         --enable-R-shlib \
         --enable-memory-profiling \
         --enable-BLAS-shlib \
         --enable-prebuilt-html \
         rdocdir=%{_docdir}/R\
         rincludedir=%{_includedir}/R \
         rsharedir=%{_datadir}/R)

Above is the relevant part of my build script.

--------------------------------------------

in config.log

checking for dgemm_ in
result: yes

checking whether double complex BLAS can be used
result: yes

checking whether the BLAS is complete
result: yes

-----------------------------------------

$ ldd bin/exec/R
linux-vdso.so.1 (0x00007ffd917ab000)
	libR.so => /usr/lib64/R/lib/libR.so (0x00007f0da24ba000)
	libRblas.so => not found
	libm.so.6 => /lib64/libm.so.6 (0x00007f0da21b1000)
	libiomp5.so => /opt/intel/compilers_and_libraries_2016.0.109/linux/compiler/lib/intel64_lin/libiomp5.so (0x00007f0da1e70000)
	libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f0da1c59000)
	libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f0da1a3c000)
	libc.so.6 => /lib64/libc.so.6 (0x00007f0da167c000)
	libdl.so.2 => /lib64/libdl.so.2 (0x00007f0da1478000)
	libblas.so.3 => /lib64/libblas.so.3 (0x00007f0da121e000)
	libgfortran.so.3 => /lib64/libgfortran.so.3 (0x00007f0da0ef3000)
	libquadmath.so.0 => /lib64/libquadmath.so.0 (0x00007f0da0cb4000)
	libreadline.so.6 => /lib64/libreadline.so.6 (0x00007f0da0a69000)
	libtre.so.5 => /lib64/libtre.so.5 (0x00007f0da0859000)
	libpcre.so.1 => /lib64/libpcre.so.1 (0x00007f0da05e9000)
	liblzma.so.5 => /lib64/liblzma.so.5 (0x00007f0da03c2000)
	libbz2.so.1 => /lib64/libbz2.so.1 (0x00007f0da01b2000)
	libz.so.1 => /lib64/libz.so.1 (0x00007f0d9ff9c000)
	librt.so.1 => /lib64/librt.so.1 (0x00007f0d9fd93000)
	libicuuc.so.54 => /lib64/libicuuc.so.54 (0x00007f0d9fa02000)
	libicui18n.so.54 => /lib64/libicui18n.so.54 (0x00007f0d9f5ab000)
	libgomp.so.1 => /lib64/libgomp.so.1 (0x00007f0d9f388000)
	/lib64/ld-linux-x86-64.so.2 (0x000055dd6cf51000)
	libtinfo.so.5 => /lib64/libtinfo.so.5 (0x00007f0d9f15e000)
	libicudata.so.54 => /lib64/libicudata.so.54 (0x00007f0d9d732000)
	libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007f0d9d3b0000)

-----------------------------------------------------------

This output is from my build directory with the package NOT YET INSTALLED.

If this output is the expected one, that's OK. I was just expecting some linking to libmkl_intel_lp64.so and libmkl_core.so

I am still scratching my head

arnaud_g_1 — Fri, 25 Sep 2015 16:11:06 GMT

I am still scratching my head since more than a week to understand what would be a correct ldd output for a executable built with shared MKL library. I can not find any answer on mailing lists etc.

Here is the problem.

I build R from source with this simple script (testing purpose). No ICC.

source /opt/intel/mkl/bin/mklvars.sh intel64

_icclibpath=/opt/intel/composerexe/compiler/lib/intel64/

MKL=" -L${MKLROOT}/lib/intel64 \
    -Wl,--start-group \
    -lmkl_gfl_ilp64 \ 
    -lmkl_core \ 
    lkml_intel_thread \
    -Wl,--end-group \
    -liomp5 -ldl -lpthread -lm"


export LDFLAGS="${LDFLAGS} -L${_icclibpath}"


export CFLAGS="-DMKL_ILP64 -m64 -I${MKLROOT}/include"
export CXXFLAGS="-DMKL_ILP64 -m64 -I${MKLROOT}/include"
export FFLAGS="-DMKL_ILP64 -m64 -I${MKLROOT}/include"
export FCFLAGS="-DMKL_ILP64 -m64 -I${MKLROOT}/include"

./configure  --prefix=/usr \
	--libdir=/usr/lib \
     	--sysconfdir=/etc/R \
     	--datarootdir=/usr/share \
     	rsharedir=/usr/share/R/ \
     	rincludedir=/usr/include/R/ \
     	rdocdir=/usr/share/doc/R/ \
     	--with-x \
     	--enable-R-shlib \
     	--with-blas="$MKL" \
     	--with-lapack \
     	F77=${_F77} \
     	FC=${_FC} \
     	LIBnn=lib

make -j4

I build on two Linux machines, with parallel studio installed in same dir (/op/intel) and same /etc/ld.conf.so intel .conf files. One machine is Archlinux and the other one Fedora.

On archlinux:

$ ldd bin/exec/R
	linux-vdso.so.1 (0x00007ffc5c1c6000)
	libR.so => /usr/lib/R/lib/libR.so (0x00007f8576a5b000)
	libgomp.so.1 => /usr/lib/libgomp.so.1 (0x00007f8576839000)
	libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007f857661c000)
	libc.so.6 => /usr/lib/libc.so.6 (0x00007f8576278000)
	libmkl_gf_lp64.so => /opt/intel/mkl/lib/intel64/libmkl_gf_lp64.so (0x00007f8575ba4000)
	libmkl_core.so => /opt/intel/mkl/lib/intel64/libmkl_core.so (0x00007f8574037000)
	libmkl_gnu_thread.so => /opt/intel/mkl/lib/intel64/libmkl_gnu_thread.so (0x00007f85732e0000)
	libdl.so.2 => /usr/lib/libdl.so.2 (0x00007f85730dc000)
	libimf.so => /opt/intel/lib/libimf.so (0x00007f8572c21000)
	libm.so.6 => /usr/lib/libm.so.6 (0x00007f8572923000)
	libgfortran.so.3 => /usr/lib/libgfortran.so.3 (0x00007f85725f9000)
	libquadmath.so.0 => /usr/lib/libquadmath.so.0 (0x00007f85723ba000)
	libreadline.so.6 => /usr/lib/libreadline.so.6 (0x00007f8572170000)
	libpcre.so.1 => /usr/lib/libpcre.so.1 (0x00007f8571f00000)
	liblzma.so.5 => /usr/lib/liblzma.so.5 (0x00007f8571cda000)
	libbz2.so.1.0 => /usr/lib/libbz2.so.1.0 (0x00007f8571aca000)
	libz.so.1 => /usr/lib/libz.so.1 (0x00007f85718b4000)
	librt.so.1 => /usr/lib/librt.so.1 (0x00007f85716ac000)
	libicuuc.so.55 => /usr/lib/libicuuc.so.55 (0x00007f8571319000)
	libicui18n.so.55 => /usr/lib/libicui18n.so.55 (0x00007f8570eb3000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f8577015000)
	libintlc.so.5 => /opt/intel/lib/libintlc.so.5 (0x00007f8570c58000)
	libgcc_s.so.1 => /usr/lib/../lib/libgcc_s.so.1 (0x00007f8570a42000)
	libncursesw.so.6 => /usr/lib/libncursesw.so.6 (0x00007f85707d5000)
	libicudata.so.55 => /usr/lib/libicudata.so.55 (0x00007f856ed1f000)
	libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007f856e99d000)

This output sounds good and I can see R is dynamically linked against some Intel libraries.

Now, same build script on Fedora 22:

	linux-vdso.so.1 (0x00007fff40dd9000)
	libblas.so.3 => /lib64/libblas.so.3 (0x00007f4c374ba000)
	libgfortran.so.3 => /lib64/libgfortran.so.3 (0x00007f4c3718f000)
	libm.so.6 => /lib64/libm.so.6 (0x00007f4c36e87000)
	libquadmath.so.0 => /lib64/libquadmath.so.0 (0x00007f4c36c47000)
	libreadline.so.6 => /lib64/libreadline.so.6 (0x00007f4c369fd000)
	libpcre.so.1 => /lib64/libpcre.so.1 (0x00007f4c3678d000)
	liblzma.so.5 => /lib64/liblzma.so.5 (0x00007f4c36566000)
	libbz2.so.1 => /lib64/libbz2.so.1 (0x00007f4c36356000)
	libz.so.1 => /lib64/libz.so.1 (0x00007f4c36140000)
	librt.so.1 => /lib64/librt.so.1 (0x00007f4c35f37000)
	libdl.so.2 => /lib64/libdl.so.2 (0x00007f4c35d33000)
	libicuuc.so.54 => /lib64/libicuuc.so.54 (0x00007f4c359a2000)
	libicui18n.so.54 => /lib64/libicui18n.so.54 (0x00007f4c3554a000)
	libgomp.so.1 => /lib64/libgomp.so.1 (0x00007f4c35328000)
	libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f4c3510c000)
	libc.so.6 => /lib64/libc.so.6 (0x00007f4c34d4b000)
	/lib64/ld-linux-x86-64.so.2 (0x0000561fcb5f8000)
	libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f4c34b34000)
	libtinfo.so.5 => /lib64/libtinfo.so.5 (0x00007f4c3490a000)
	libicudata.so.54 => /lib64/libicudata.so.54 (0x00007f4c32ede000)
	libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007f4c32b5c000)

No links against Intel libs.

I can't find where the difference comes from as both machines build environment are similar. Why this difference? Why I can't get any link to Intel libs in Fedora 22? Where shall I look to find any clue?

Thank you for help.

Look at your configure and

TimP — Fri, 25 Sep 2015 17:01:35 GMT

Look at your configure and build scripts more carefully. Assuming you have sourced the intel compilervars script, the configure should set up with your exports to use ifort and not gfortran. You will need to correct anything which causes configure tests to discard ifort. It may not be surprising if a failing configure script comes out different between distros. Hve you checked whether R needs an F90 export as well as F77 and FC? It would not do to have F90 default to gfortran when another is set to ifort.

In your Fedora case, it apparently failed to find MKL (possibly because you set up to link it from ifort and not gfortran) and so used libblas. Among other problems, way back you showed a configure step fragment which was trying to link both the gnu and Intel OpenMP libraries, as well as both ifort and gfortran run-time, so that's already wrong.

If you need your bad configures to stop earlier without depending on your subsequent review, perhaps you should remove libblas from your linux installation. libblas may be capable of co-existing with ifort, but liblapack would not unless you used ifort to rebuild it.

Your archlinux ldd result may be typical of a build with gfortran calling MKL. As the docs should tell you, libmkl_gf_lp64 and libmkl_gnu_thread may be employed so as to use libgomp instead of libiomp, if you aren't using ifort.

Tim,

arnaud_g_1 — Sun, 27 Sep 2015 11:53:22 GMT

Tim,

Thank you for all these precisions. Following your advices, I removed Lapack (providing BLAS) from my system. I still kept OpenBLAS; I shrink my script to the bare minimum (i.e no ifort, no icc, no intel thread). If I am right, the following script must only link BLAS to shared Intel MKL.

#! /bin/sh
export MKL=/opt/intel/compilers_and_libraries_2016.0.109/linux/mkl
MKL=" -L${_mkllibpath} \
-Wl,--start-group \
    -lmkl_gf_lp64 \
    -lmkl_gnu_thread \
    -lmkl_core \
-Wl,--end-group \
-lgomp -lpthread"

./configure --prefix=/usr \
--libdir=/usr/lib \
--datarootdir=/usr/share \
rsharedir=/usr/share/R/ \
rincludedir=/usr/include/R/ \
rdocdir=/usr/share/doc/R/ \
--with-blas="${MKL}" \
--with-lapack \
--enable-R-shlib 

make -j4

As to NOT polluate my build nevironment, I just export the MKL path and din't source neither the mklvars nor the compilervars scripts.

1- Is this script correct ?

If yes, I still get the same difference in my two systems. I honestly played with all kind of configuration, environment varaibes, etc.

I still do not know where the issue comes from.

Hi Arnaud,

Ying_H_Intel — Mon, 28 Sep 2015 02:22:08 GMT

Hi Arnaud,

We haven't such machine to test too. In order to move forward, I may suggest to quick and direct link mkl blas library to your Rblas library as below article.

https://software.intel.com/en-us/articles/quick-linking-intel-mkl-blas-lapack-to-r

Please let us know if it works.

Regard,

Ying

And add comment about #4.

Ying_H_Intel — Mon, 28 Sep 2015 02:30:24 GMT

And add comment about #4.

MKL=" -L${MKLROOT}/lib/intel64 \
    -Wl,--start-group \
    -lmkl_gfl_ilp64 \
    -lmkl_core \
    lkml_intel_thread \
    -Wl,--end-group \
    -liomp5 -ldl -lpthread -lm"

If you copy the script from your build file, it is wrong. As you see, there is not such library -lmkl_gfl_ilp64 , it should be -lmkl_gl_ilp64.

Best Regards,
Ying

I totally removed from my

arnaud_g_1 — Mon, 28 Sep 2015 07:08:00 GMT

I totally removed from my machine all BLAS/OpenBlas/Lapack realted libraries. Things are improving a litle bit, as I have now a few links to Intel, but still no signs of MKL. I do not know why MKL is not found at all, and what shared library should be linked to: libmkl_core.so or libmkl_rt.so ?

Below is the build script

#! /bin/sh

source /opt/intel/compilers_and_libraries/linux/mkl/bin/mklvars.sh intel64
source /opt/intel/bin/compilervars.sh intel64

_mkllibpath=${MKLROOT}/lib/intel64/intel64_lin


MKL=" -L${_mkllibpath} \
    -Wl,--start-group \
        -lmkl_intel_lp64 \
        -lmkl_intel_thread \
        -lmkl_core \
    -Wl,--end-group \
    -liomp -lpthread"

export CC="icc "
export CXX="icpc"
export AR="xiar"
export LD="xild"
export F77="ifort"
export FC="ifort"


./configure --with-lapack \
    --with-blas="${MKL}"

Now ldd :

% ldd bin/exec/R
	linux-vdso.so.1 (0x00007ffdb557c000)
	libRblas.so => not found
	libifport.so.5 => /opt/intel/compilers_and_libraries_2016.0.109/linux/compiler/lib/intel64/libifport.so.5 (0x00007f277fcde000)
	libifcore.so.5 => /opt/intel/compilers_and_libraries_2016.0.109/linux/compiler/lib/intel64/libifcore.so.5 (0x00007f277f97a000)
	libimf.so => /opt/intel/compilers_and_libraries_2016.0.109/linux/compiler/lib/intel64/libimf.so (0x00007f277f481000)
	libsvml.so => /opt/intel/compilers_and_libraries_2016.0.109/linux/compiler/lib/intel64/libsvml.so (0x00007f277e5c2000)
	libm.so.6 => /lib64/libm.so.6 (0x00007f277e2ba000)
	libirc.so => /opt/intel/compilers_and_libraries_2016.0.109/linux/compiler/lib/intel64/libirc.so (0x00007f277e05a000)
	libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f277de3e000)
	libdl.so.2 => /lib64/libdl.so.2 (0x00007f277dc3a000)
	libreadline.so.6 => /lib64/libreadline.so.6 (0x00007f277d9ef000)
	libpcre.so.1 => /lib64/libpcre.so.1 (0x00007f277d77f000)
	liblzma.so.5 => /lib64/liblzma.so.5 (0x00007f277d559000)
	libbz2.so.1 => /lib64/libbz2.so.1 (0x00007f277d348000)
	libz.so.1 => /lib64/libz.so.1 (0x00007f277d132000)
	librt.so.1 => /lib64/librt.so.1 (0x00007f277cf2a000)
	libicuuc.so.54 => /lib64/libicuuc.so.54 (0x00007f277cb98000)
	libicui18n.so.54 => /lib64/libicui18n.so.54 (0x00007f277c741000)
	libiomp5.so => /opt/intel/compilers_and_libraries_2016.0.109/linux/compiler/lib/intel64/libiomp5.so (0x00007f277c400000)
	libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f277c1e8000)
	libc.so.6 => /lib64/libc.so.6 (0x00007f277be28000)
	/lib64/ld-linux-x86-64.so.2 (0x00005597ed6e7000)
	libintlc.so.5 => /opt/intel/compilers_and_libraries_2016.0.109/linux/compiler/lib/intel64/libintlc.so.5 (0x00007f277bbc9000)
	libtinfo.so.5 => /lib64/libtinfo.so.5 (0x00007f277b99e000)
	libicudata.so.54 => /lib64/libicudata.so.54 (0x00007f2779f73000)
	libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007f2779bf0000)

Sounds a litle bit better, but nothing about libmkl

Hi arnaud,

Ying_H_Intel — Tue, 29 Sep 2015 01:40:01 GMT

Hi arnaud,

It may be some tiny place cause the problem, for example,

	
				./configure

	
				26
				    --with-blas="${MKL}"
			
	  --with-lapack \

But anyway, it is good status for try the below.

For developers who have R, please locate the path of libRblas.so and libRlapack.so, for example, $cd /usr/local/lib64/R

$ cd lib

$ mv libRblas.so libRblas.so.keep

$ln –s /opt/intel/composer_xe_2015.0.090/mkl/lib/intel64/libmkl_rt.so libRblas.so

The same way, you can replace the LAPACK libRlapack.so library too

($mv libRlapack.so libRlapack.so.keep

$ln –s /opt/intel/composer_xe_2015.0.090/mkl/lib/intel64/libmkl_rt.so libRlapack.so)

Best Regards,

Ying

I found the root of my issue.

arnaud_g_1 — Tue, 29 Sep 2015 07:58:12 GMT

I found the root of my issue. When building R as described above, there is a shared libRblas built in BUILD_FOLDER/lib/libRblas.so

$ ldd lib/libRblas.so

	linux-vdso.so.1 (0x00007fffd61e6000)
	libmkl_rt.so => /opt/intel/mkl/lib/intel64_lin/libmkl_rt.so (0x00007f3bf70fb000)
	libiomp5.so => /opt/intel/lib/intel64_lin/libiomp5.so (0x00007f3bf6db9000)
	libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f3bf6b9d000)
	libimf.so => /opt/intel/lib/intel64_lin/libimf.so (0x00007f3bf66a5000)
	libsvml.so => /opt/intel/lib/intel64_lin/libsvml.so (0x00007f3bf57e5000)
	libirng.so => /opt/intel/lib/intel64_lin/libirng.so (0x00007f3bf55dd000)
	libm.so.6 => /lib64/libm.so.6 (0x00007f3bf52d5000)
	libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f3bf50bd000)
	libintlc.so.5 => /opt/intel/lib/intel64_lin/libintlc.so.5 (0x00007f3bf4e5e000)
	libc.so.6 => /lib64/libc.so.6 (0x00007f3bf4a9e000)
	libdl.so.2 => /lib64/libdl.so.2 (0x00007f3bf4899000)
	/lib64/ld-linux-x86-64.so.2 (0x0000561dc0ad6000)

In the output show above, I used mkl_rt which replace now the three : -mkl_intel_lp64 -mkl_intel_thread and mkl_core.

So I guess it is now the exoected output when running ldd against libRblas.so.