Re: [Rd] Build R with MKL and ICC
On Tue, Sep 29, 2015 at 8:11 PM, Nathan Kurz wrote:
> Hi Arnaud --
>
> I'm glad it's working for you. I'm not sure I understand your final
> answer. Are you saying that the version I posted worked for you as
> given, or that you had to remove some of the other options?
I say it works perfectly when using the single dynamic library
(lmkl_rt): MKL=" -L${_mkllibpath} -lmkl_rt -lpthread -lm"
N.B: not sure the -lm is needed, and It builds without it. It seems it
may trigger some issues on. See[0]. Thus I removed it
> Perhaps you could post the full final recipe in a way that others can
> copy and paste if they find this thread in the future?
Here it is. The script is writen for Parallel studio 2016. Change path
accordingly if composerxe 2015.
libRlib and libRblas are build as shared librairies. It build with
static libraries too.
More options can be added to configure.
Best is to source mklvars and compilervars in a script so it won't
polluated your shell environment once the build is done.
---
#! /bin/sh
source /opt/intel/compilers_and_libraries_2016.0.109/linux/mkl/bin/mklvars.sh
intel64
source /opt/intel/bin/compilervars.sh intel64
_icclibpath=/opt/intel/compilers_and_lbraries_2016.0.109/linux/compiler/lib/intel64/
_mkllibpath=${MKLROOT}/lib/intel64/
_omp_lib=/opt/intel/lib/intel64/
MKL=" -L${_mkllibpath} -lmkl_rt -lpthread"
export CC="icc"
export CXX="icpc"
export AR="xiar"
export LD="xild"
export F77="ifort"
export CFLAGS="-g -O3 -xHost -I${MKLROOT}/include"
export CXXFLAGS="-g -O3 -xHost -I${MKLROOT}/include"
export FFLAGS="-I${MKLROOT}/include"
export FCFLAGS="-I${MKLROOT}/include"
# shared libs
./configure --with-blas="${MKL}" --enable-R-shlib --enable-BLAS-shlib
# static libs
./configure --with-blas="${MKL}" --with-lapack
make -j4
--
from inside the build folder:
-
$ldd bin/exec/R
linux-vdso.so.1 (0x7ffc1e853000)
libR.so => /usr/lib64/R/lib/libR.so (0x7f747091f000)
libRblas.so => not found !! is not yet installed in the machine !!
libm.so.6 => /lib64/libm.so.6 (0x7f7470616000)
libiomp5.so => /opt/intel/lib/intel64_lin/libiomp5.so (0x7f74702d5000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x7f74700be000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x7f746fea1000)
libc.so.6 => /lib64/libc.so.6 (0x7f746fae1000)
libdl.so.2 => /lib64/libdl.so.2 (0x7f746f8dd000)
libblas.so.3 => not found !! we don't need it !!
libgfortran.so.3 => /lib64/libgfortran.so.3 (0x7f746f5b1000)
libquadmath.so.0 => /lib64/libquadmath.so.0 (0x7f746f372000)
libreadline.so.6 => /lib64/libreadline.so.6 (0x7f746f127000)
libtre.so.5 => /lib64/libtre.so.5 (0x7f746ef17000)
libpcre.so.1 => /lib64/libpcre.so.1 (0x7f746eca7000)
liblzma.so.5 => /lib64/liblzma.so.5 (0x7f746ea8)
libbz2.so.1 => /lib64/libbz2.so.1 (0x7f746e87)
libz.so.1 => /lib64/libz.so.1 (0x7f746e65a000)
librt.so.1 => /lib64/librt.so.1 (0x7f746e451000)
libicuuc.so.54 => /lib64/libicuuc.so.54 (0x7f746e0c)
libicui18n.so.54 => /lib64/libicui18n.so.54 (0x7f746dc69000)
libgomp.so.1 => /lib64/libgomp.so.1 (0x7f746da46000)
/lib64/ld-linux-x86-64.so.2 (0x55fcb8058000)
libtinfo.so.5 => /lib64/libtinfo.so.5 (0x7f746d81c000)
libicudata.so.54 => /lib64/libicudata.so.54 (0x7f746bdf)
libstdc++.so.6 => /lib64/libstdc++.so.6 (0x7f746ba6e000)
$ ldd lib/libRblas.so
linux-vdso.so.1 (0x7ffc5f3da000)
libmkl_rt.so => /opt/intel/mkl/lib/intel64_lin/libmkl_rt.so (0x7f232203e000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x7f2321e21000)
libm.so.6 => /lib64/libm.so.6 (0x7f2321b19000)
libimf.so => /opt/intel/lib/intel64_lin/libimf.so (0x7f2321621000)
libsvml.so => /opt/intel/lib/intel64_lin/libsvml.so (0x7f2320762000)
libirng.so => /opt/intel/lib/intel64_lin/libirng.so (0x7f2320559000)
libiomp5.so => /opt/intel/lib/intel64_lin/libiomp5.so (0x7f2320218000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x7f2320001000)
libintlc.so.5 => /opt/intel/lib/intel64_lin/libintlc.so.5 (0x7f231fda1000)
libc.so.6 => /lib64/libc.so.6 (0x7f231f9e1000)
libdl.so.2 => /lib64/libdl.so.2 (0x7f231f7dd000)
/lib64/ld-linux-x86-64.so.2 (0x55ce12e09000)
--
>
> Also, did you determine if the the same approach worked for linking to
> MKL worked when using a non-Intel compiler? That is, can you
> substitute the gcc or clang tool names and get the same result?
No. I was not enable to do it with gcc. More tries are needed with
some variations.
>
> --nate
>
> On Tue, Sep 29, 2015 at 9:07 AM, arnaud gaboury
> wrote:
>> On Wed, Sep 9, 2015 at 11:26 PM, Nathan Kurz wrote:
>>>
>>> As a short and simple approach, I just compiled the current R release
>>> on Ubuntu with ICC and MKL using just this:
>>>
>>> $ ta
Re: [Rd] Error possibly related with environments/namespace
Frederico Mestre gmail.com> writes:
>
> Hello all,
>
> I've got a problem with a function in a R package I've developed
> (MetaLandSim).
>
The function with the problem is a GRASS script embedded in a portmanteau
function (doing too much at once). This list is not appropriate, and
http://lists.osgeo.org/mailman/listinfo/grass-stats would be much more
appropriate, as this has nothing to do with the development of R internals.
The function should return an S3 object (list of objects) with plot and
summary methods. Then you can see where problems are happening.
>
> However if I load the exact same function in R it runs perfectly well.
>
> This has something to do with environments, but I can't understand whats
> wrong. It is also related with the plotting, since if I set the argument
> plot.directions to FALSE I get no error.
>
> Here's the code:
>
> #Loading packages
> library(MetaLandSim)
> library(rgrass7)
>
> #Loading required data
> data(rg_exp)
>
> #Loading required maps
> presences <- system.file("examples/presences.asc", package="MetaLandSim")
> mask <- system.file("examples/landmask.asc", package="MetaLandSim")
>
> #Start GRASS using rgrass7
> initGRASS("C:/Program Files (x86)/GRASS GIS 7.0.0", home=tempdir())
>
> #Running function
> range.map <- range_raster(presences.map=presences, re.out=rg_exp,
> mask.map=mask,plot.directions=TRUE)
The example fails because you expect a mask to be set, and remove it - if it
isn't there, the GRASS script fails. Adding:
execGRASS("r.mask", raster="map.mask") gets me further, but isn't the
problem, which is (in this case):
Browse[2]>
debug: image(raster(readRAST("Nprobability")), main = "Northern probability")
Browse[2]>
Creating BIL support files...
Exporting raster as floating values (bytes=8)
100%
Error in image.default(raster(readRAST("Nprobability")), main = "Northern
probability") :
'z' must be a matrix
so there is an issue here, which might be addressed by raster::raster
(untried). Main take-home point - write simple functions and leave plota and
summaries to methods used on the output objects - anything else is hard to
debug and maintain.
Hope this clarifies,
Roger
>
> Cheers,
> Frederico Mestre
> ᐧ
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
