Package Details: r-mkl 3.3.1-2

Git Clone URL: https://aur.archlinux.org/r-mkl.git (read-only)
Package Base: r-mkl
Description: Language and environment for statistical computing and graphics, linked with Intel's MKL.
Upstream URL: http://www.r-project.org/
Keywords: hpc mathematics modelling r statistics
Licenses: GPL
Conflicts: r
Provides: r=3.3.1,r-mkl=3.3.1
Submitter: giniu
Maintainer: alexanderp
Last Packager: alexanderp
Votes: 14
Popularity: 0.171816
First Submitted: 2010-05-06 00:10
Last Updated: 2016-07-05 16:56

Required by (102)

Sources (4)

Pinned Comments

alexanderp commented on 2016-06-17 00:20

The latest update (3.3.0-2):
- fixes compilation with icc/ifort
- icc/ifort are enabled by default now
- adds floating point precision options to icc
- removes i686 build options

You'll notice an error while checking the Matrix package. This is due to the LAPACK functions which error out on zero size matrices.

Latest Comments

AnRe005 commented on 2016-08-07 09:22

Maybe a little late but,

--------------------------------------------------------------------------------------
The package compiles and runs well, however I can't install anything from within R, as there are always undefined symbols associated with intel compilers. For instance, if I try install.package("igraph"), the compilation runs well, but the package fails to load with:

Error in dyn.load(file, DLLpath = DLLpath, ...) :
unable to load shared object '/usr/lib/R/library/igraph/libs/igraph.so':
/usr/lib/R/library/igraph/libs/igraph.so: undefined symbol: for_cpstr
--------------------------------------------------------------------------------------

**This error disappears when 'lifcore' is added to 'BLAS_LIBS' in the Makeconf file**

--------------------------------------------------------------------------------------
Rcmdr fails with:

unable to load shared object '/usr/lib/R/library/quantreg/libs/quantreg.so':
/usr/lib/R/library/quantreg/libs/quantreg.so: undefined symbol: etime_
--------------------------------------------------------------------------------------

**This error disappears when 'lifport' is added to 'BLAS_LIBS' in the Makeconf file**

So I was able to compile and install the 'igraph' package with icc.

The 'quantreg' package still doesn't compile fine and throws the following error message:

/opt/intel/composerxe/linux/compiler/lib/intel64/libifport.so.5: undefined symbol: __FFfrand

greenisagoodcolo commented on 2016-07-12 20:50

Thank you Lennartv. That was a big help :-D

AnRe005 commented on 2016-07-05 07:09

The md5sum and md512sum for r.png have changed.

New md5sum: 8e0c51650b8a63f110fa7b09e699e9c4

New md512sum: 1491b01d3d14b86d26c383e00e2305858a52ddd498158c9f7f6b33026ee01f246408b1676cffea73f7783c8c4cf546285705c43c0286adbd75ad77706918b5fe

lennartv commented on 2016-06-25 19:49

[SOLVED]: Following your solution proposal to compile packages where icc fails...

My .R/Makevars is:
CC=gcc
CXX=g++
CXX1X=g++
CFLAGS=-mtune=native -g -O3 -Wall
CXXFLAGS=-mtune=native -g -O3 -Wall
______________________________________
Installing "quantreg" I get:

Error in dyn.load(file, DLLpath = DLLpath, ...) :
unable to load shared object '/home/lennartv/R/x86_64-pc-linux-gnu-library/3.3/quantreg/libs/quantreg.so':
/home/lennartv/R/x86_64-pc-linux-gnu-library/3.3/quantreg/libs/quantreg.so: undefined symbol: __must_be_linked_with_icc_or_xild
Error: loading failed

Thanks in advance for your help. I highly appreciate your package in general.

____________
Never mind. This solved the issue for me:

CC=gcc
CXX=g++
CXX1X=g++
CFLAGS=-mtune=native -g -O3 -Wall
CPPFLAGS=
CXXFLAGS=-mtune=native -g -O3 -Wall
FC=gfortran
FCFLAGS=-O3 -fopenmp
F77=gfortran
FFLAGS=-O3 -fopenmp

alexanderp commented on 2016-06-22 20:27

Hello wast3,

yes, some packages fail to compile with icc. You can switch to gcc temporarily by creating a .R/Makevars file.

Or, you can build the package with gcc.

wast3 commented on 2016-06-22 19:57

The package compiles and runs well, however I can't install anything from within R, as there are always undefined symbols associated with intel compilers. For instance, if I try install.package("igraph"), the compilation runs well, but the package fails to load with:

Error in dyn.load(file, DLLpath = DLLpath, ...) :
unable to load shared object '/usr/lib/R/library/igraph/libs/igraph.so':
/usr/lib/R/library/igraph/libs/igraph.so: undefined symbol: for_cpstr


Rcmdr fails with:

unable to load shared object '/usr/lib/R/library/quantreg/libs/quantreg.so':
/usr/lib/R/library/quantreg/libs/quantreg.so: undefined symbol: etime_

Guess something must be missing either from this package or intel-mkl

chendaniely commented on 2016-06-19 03:34

I'm having a problem with the update (used pacaur and yaourt):


==> Extracting sources...
-> Extracting R-3.3.0.tar.gz with bsdtar
==> Starting prepare()...
==> Starting build()...
checking build system type... x86_64-pc-linux-gnu
checking host system type... x86_64-pc-linux-gnu
loading site script './config.site'
loading build-specific script './config.site'
checking for pwd... /usr/bin/pwd
checking whether builddir is srcdir... yes
checking for working aclocal... found
checking for working autoconf... found
checking for working automake... found
checking for working autoheader... found
checking whether ln -s works... yes
checking for bison... bison -y
checking for xiar... xiar
checking for a BSD-compatible install... /usr/bin/install -c
checking for sed... /usr/bin/sed
checking for which... /usr/bin/which
checking for less... /usr/bin/less
checking for gtar... no
checking for gnutar... no
checking for tar... /usr/bin/tar
checking for tex... /usr/bin/tex
checking for pdftex... /usr/bin/pdftex
checking for pdflatex... /usr/bin/pdflatex
checking for makeindex... /usr/bin/makeindex
checking for texi2any... /usr/bin/texi2any
checking whether texi2any version is at least 5.1... yes
checking for ginstall-info... no
checking for install-info... /usr/bin/install-info
checking for texi2dvi... /usr/bin/texi2dvi
checking for kpsewhich... /usr/bin/kpsewhich
checking for latex inconsolata package... found zi4.sty
checking for unzip... /usr/bin/unzip
checking for zip... /usr/bin/zip
checking for gzip... /usr/bin/gzip
checking for bzip2... /usr/bin/bzip2
checking for firefox... /usr/bin/firefox
using default browser ... /usr/bin/firefox
checking for acroread... no
checking for acroread4... no
checking for xdg-open... /usr/bin/xdg-open
checking for notangle... false
checking for realpath... /usr/bin/realpath
checking for pkg-config... /usr/bin/pkg-config
checking for gcc... icc -std=c99
checking whether the C compiler works... no
configure: error: in `/tmp/yaourt-tmp-dchen/aur-r-mkl/src/R-3.3.0':
configure: error: C compiler cannot create executables



greenisagoodcolo commented on 2016-06-17 18:25

Thank you Alexanderp!

AnRe005 commented on 2016-06-17 11:28

Thanks for the fix. :-)

alexanderp commented on 2016-06-17 09:28

I pushed another update to fix errors due to missing dependencies.

greenisagoodcolo commented on 2016-06-17 06:49

Manually installed intel-mkl from git/MAKEPKG instead of yaourt. Tried the same thing by cloning the repo and makepkg for r-mkl and running into this error.

/home/matt/aur/r-mkl/r-mkl/PKGBUILD: line 87: /opt/intel/mkl/bin/mklvars.sh: No such file or directory

So I manually installed intel-compiler, then ran into another error after once again trying makepkg for r-mkl.

configure: error: in `/home/matt/aur/r-mkl/r-mkl/src/R-3.3.0':
configure: error: C compiler cannot create executables
See `config.log' for more details
==> ERROR: A failure occurred in build().
Aborting...

alexanderp commented on 2016-06-17 00:20

The latest update (3.3.0-2):
- fixes compilation with icc/ifort
- icc/ifort are enabled by default now
- adds floating point precision options to icc
- removes i686 build options

You'll notice an error while checking the Matrix package. This is due to the LAPACK functions which error out on zero size matrices.

alexanderp commented on 2016-06-16 19:26

That was an error from Intel's side. Try again now.

You won't be able to build intel-mkl with yaourt anyway. I suggest cloning the AUR repo locally and building with "$ makepkg -scCi"

greenisagoodcolo commented on 2016-06-16 19:16

Hello all,

I've tried three times to install r-mkl with yaourt. I keep getting this error...any thoughts?

Thank you.

==> Retrieving sources...
-> Downloading parallel_studio_xe_2016_update3.tgz...
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
97 4030M 97 3937M 0 0 3239k 0 0:21:14 0:20:44 0:00:30 4321k
curl: (23) Failed writing body (872 != 10136)
==> ERROR: Failure while downloading http://registrationcenter-download.intel.com/akdlm/irc_nas/9061/parallel_studio_xe_2016_update3.tgz
Aborting...
==> ERROR: Makepkg was unable to build intel-parallel-studio-xe.

AnRe005 commented on 2016-06-16 06:42

Thanks for your reply.

Then I'll use the GCC compilers until this is fixed.

alexanderp commented on 2016-06-15 17:18

AnRe005, the latest changes to Intel Parallel Studio introduced some changes which have broken compilation with icc and ifort.

AnRe005 commented on 2016-06-15 14:57

Hey,

I tried to compile the pkg with the intel compilers and added the -fp-model precise flag to the _intel_cc_opt=... line.

The compilation fails with the message:

checking whether ifort and icc agree on int and double... configure: WARNING: ifort and icc disagree on int and double
configure: error: Maybe change CFLAGS or FFLAGS?

What else do I have to adapt?

Thanks in advance

alexanderp commented on 2016-06-03 11:21

No problem. Please keep us updated.

nacnudus commented on 2016-06-03 11:14

I think this is an R problem, since by running the test script mgcv-Ex.R with R version 3.2.4 (binary install), it encountered the same error in line 1940:
cl <- makeCluster(nc)
A workaround is to change the PKGBUILD to do `make check` instead of `make check-recommended`, to avoid this check altogether.
I'll follow this up with the R maintainers.

nacnudus commented on 2016-06-03 10:06

Intel(R) Core(TM) i7-4600U CPU @ 2.10GHz

Sorry for my slow replies. I don't seem to be getting notifications despite subscribing to the thread.

alexanderp commented on 2016-06-02 18:59

Yes, the default is GCC. On my i7-2640m the "checking examples" step doesn't take more than 1-2min. Which CPU do you have?

nacnudus commented on 2016-06-02 18:10

Yes, I interrupted it after about eight hours with no activity on the process. Am I compiling it with GCC? It seems to be the default since
#_CC="icc" # comment to build without the Intel compiler
has been commented out by default.

alexanderp commented on 2016-06-02 16:27

I compiled again with GCC and get no such error.

This line seems strange to me:

* checking examples ...^C ERROR

Did you press Ctrl+C while in the middle of checking the examples?

nacnudus commented on 2016-06-02 14:00

Installation stalls on package mgcv with the following:

checking package 'mgcv'
* using log directory ‘/tmp/yaourt-tmp-nacnudus/aur-r-mkl/src/R-3.3.0/tests/mgcv.Rcheck’
* using R version 3.3.0 (2016-05-03)
* using platform: x86_64-pc-linux-gnu (64-bit)
* using session charset: UTF-8
* checking for file ‘mgcv/DESCRIPTION’ ... OK
* this is package ‘mgcv’ version ‘1.8-12’
* checking package namespace information ... OK
* checking package dependencies ... OK
* checking if this is a source package ... OK
* checking if there is a namespace ... OK
* checking for executable files ... OK
* checking for hidden files and directories ... OK
* checking for portable file names ... OK
* checking for sufficient/correct file permissions ... OK
* skipping installation test
* checking installed package size ... OK
* checking package directory ... OK
* checking DESCRIPTION meta-information ... OK
* checking top-level files ... OK
* checking for left-over files ... OK
* checking index information ... OK
* checking package subdirectories ... OK
* checking R files for non-ASCII characters ... OK
* checking R files for syntax errors ... OK
* checking whether the package can be loaded ... OK
* checking whether the package can be loaded with stated dependencies ... OK
* checking whether the package can be unloaded cleanly ... OK
* checking whether the namespace can be loaded with stated dependencies ... OK
* checking whether the namespace can be unloaded cleanly ... OK
* checking dependencies in R code ... OK
* checking S3 generic/method consistency ... OK
* checking replacement functions ... OK
* checking foreign function calls ... OK
* checking R code for possible problems ... OK
* checking Rd files ... OK
* checking Rd metadata ... OK
* checking Rd cross-references ... NOTE
Package unavailable to check Rd xrefs: ‘gam’
* checking for missing documentation entries ... OK
* checking for code/documentation mismatches ... OK
* checking Rd \usage sections ... OK
* checking Rd contents ... OK
* checking for unstated dependencies in examples ... OK
* checking contents of ‘data’ directory ... OK
* checking data for non-ASCII characters ... OK
* checking data for ASCII and uncompressed saves ... OK
* checking line endings in C/C++/Fortran sources/headers ... OK
* checking line endings in Makefiles ... OK
* checking compilation flags in Makevars ... OK
* checking for GNU extensions in Makefiles ... OK
* checking for portable use of $(BLAS_LIBS) and $(LAPACK_LIBS) ... OK
* checking compiled code ... NOTE
Note: information on .o files is not available
* checking examples ...^C ERROR
Running examples in ‘mgcv-Ex.R’ failed
The error most likely occurred in:

> ### Name: mgcv.parallel
> ### Title: Parallel computation in mgcv.
> ### Aliases: mgcv.parallel
> ### Keywords: package models smooth regression
>
> ### ** Examples
>
> ## illustration of multi-threading with gam...
>
> require(mgcv);set.seed(9)
> dat <- gamSim(1,n=2000,dist="poisson",scale=.1)
Gu & Wahba 4 term additive model
> k <- 12;bs <- "cr";ctrl <- list(nthreads=2)
>
> system.time(b1<-gam(y~s(x0,bs=bs)+s(x1,bs=bs)+s(x2,bs=bs,k=k)
+ ,family=poisson,data=dat,method="REML"))[3]
elapsed
0.088
>
> system.time(b2<-gam(y~s(x0,bs=bs)+s(x1,bs=bs)+s(x2,bs=bs,k=k),
+ family=poisson,data=dat,method="REML",control=ctrl))[3]


Then hundreds of lines of:

OpenBLAS Warning : Detect OpenMP Loop and this application may hang. Please rebuild the library with USE_OPENMP=1 option.

Finally:

elapsed
5.795
>
> ## Poisson example on a cluster with 'bam'.
> ## Note that there is some overhead in initializing the
> ## computation on the cluster, associated with loading
> ## the Matrix package on each node. For this reason the
> ## sample sizes here are very small to keep CRAN happy, but at
> ## this low sample size you see little advantage of parallel computation.
>
> k <- 13
> dat <- gamSim(1,n=6000,dist="poisson",scale=.1)
Gu & Wahba 4 term additive model
> require(parallel)
Loading required package: parallel
> nc <- 2 ## cluster size, set for example portability
> if (detectCores()>1) { ## no point otherwise
+ cl <- makeCluster(nc)
+ ## could also use makeForkCluster, but read warnings first!
+ } else cl <- NULL

Execution halted
* checking PDF version of manual ... OK
* DONE

Status: 1 ERROR, 2 NOTEs
See
‘/tmp/yaourt-tmp-nacnudus/aur-r-mkl/src/R-3.3.0/tests/mgcv.Rcheck/00check.log’
for details.


Makefile.common:404: recipe for target 'test-Packages-Recommended' failed
make[1]: *** [test-Packages-Recommended] Interrupt
Makefile:239: recipe for target 'check-recommended' failed
make: *** [check-recommended] Interrupt

syne commented on 2016-05-17 13:39

if you're installing intel-mkl etc, edit the PKGBUILD line 299-300 from
ln -s ./${_composer_xe_dir} composerxe-${_year}
ln -s ./composerxe-${_year} composerxe
to
ln -s ./${_composer_xe_dir} composerxe


don't even know why that second symlink is necessary... that fixed the mklvars problem for me.

alexanderp commented on 2016-05-16 22:04

Hmm I cannot seem to be able to reproduce your error.
Is mklvars.sh present on your system?

jabranham commented on 2016-05-16 21:17

I get an error when this tries to install. It complains that:

/opt/intel/mkl/bin/mklvars.sh: No such file or directory

alexanderp commented on 2016-05-04 12:55

Warning: The newest version of the Intel Composer XE 2016 (update 3) breaks compatibility when using the Intel compilers (icc + ifort). With GCC and GFortran it compiles fine.

alexanderp commented on 2016-02-04 23:59

Hi tetonedge and adalardo.

I've fixed the url error.

I've also fixed the compilation with gcc to correctly use the MKL now and disabled the shared BLAS lib to speed up R. As a consequence, external libraries will need to be recompiled.

Additionally, OpenMP is now enabled by default for both icc and gcc (using Intel's libiomp5.)

On my laptop (i7-2640m), I get the following benchmark scores using http://r.research.att.com/benchmarks/R-benchmark-25.R :

* R 3.2.3 + intel-mkl-2016_update1 + r-mkl (icc/ifort)
Total time for all 15 tests_________________________ (sec): 6.072
Overall mean (sum of I, II and III trimmed means/3)_ (sec): 0.387

* R 3.2.3 + intel-mkl-2016_update1 + r-mkl (gcc/gfortran)
Total time for all 15 tests_________________________ (sec): 6.309
Overall mean (sum of I, II and III trimmed means/3)_ (sec): 0.405

adalardo commented on 2016-02-03 19:52

Thank for the package alexanderp!
I found an error in PKGBUILD, to fix it just change line:

url=('http://www.r-project.org/')

to

url="http://www.r-project.org/"

This is the bug commented by tetonedge.

I was not able to compile the package using icc. I comment the line:

#_CC="icc" # comment to build without the Intel compiler

and works!
Best,
Alexandre

tetonedge commented on 2016-02-01 14:20

I get ==> ERROR: url should not be an array
with the new PKGBUILD

alexanderp commented on 2016-01-20 20:59

I updated the PKGBUILD for R-3.2.3. The compilation uses Intel's MKL by default now, unless if commented out in the PKGBUILD.

I also added OpenMP support when compiling with gcc.

alexanderp commented on 2015-12-20 15:30

Hi. I had trouble compiling with the Intel compilers since some old and non-optimized options were used in your PKGBUILD. Here is a patch which fixes the PKGBUILD and compiles with Intel MKL, Intel BLAS (multi-threaded) and compiler optimizations:

diff --git a/PKGBUILD b/PKGBUILD
index c50e724..a7934a6 100644
--- a/PKGBUILD
+++ b/PKGBUILD
@@ -15,7 +15,7 @@ conflicts=('r')
depends=('intel-mkl' 'bzip2' 'libpng' 'libjpeg' 'libtiff'
'ncurses' 'pcre' 'readline' 'zlib' 'perl' 'gcc-libs'
'libxt' 'libxmu' 'pango' 'xz' 'desktop-file-utils' 'zip' 'unzip')
-makedepends=('jdk8-openjdk' 'gcc-fortran' 'tk')
+makedepends=('jdk8-openjdk-infinality' 'gcc-fortran' 'tk')
optdepends=('tk: tcl/tk interface' 'texlive-bin: latex sty files'
'icc: intel compiler' 'icpc: intel compiler' 'xiar: intel compiler'
'xild: intel compiler')
@@ -39,13 +39,13 @@ sha512sums=('71ba470875262b9f00fb6970f209788df4dad30e0a28373b824b60d8bc6401afb77

if [ "$CARCH" == "x86_64" ]; then
_intel_arch=intel64
- _intel_lib=mkl_gf_lp64
+ _intel_lib=mkl_intel_lp64
elif [ "$CARCH" == "i686" ]; then
_intel_arch=ia32
_intel_lib=mkl_gf
fi

-#_CC="icc" # uncomment to build with the Intel compiler
+_CC="icc" # uncomment to build with the Intel compiler

prepare() {
cd R-${pkgver}
@@ -60,10 +60,17 @@ prepare() {
build() {
# Set up the environment for MKL
source /opt/intel/mkl/bin/mklvars.sh ${_intel_arch}
+ source /opt/intel/composerxe/linux/bin/ifortvars.sh ${_intel_arch}
_icclibpath=$(echo $MKLROOT | sed "s%mkl%compiler%g")/lib/${_intel_arch}
_mkllibpath=$MKLROOT/lib/${_intel_arch}
- _mkllibs=" -fopenmp -Wl,--no-as-needed -L${_mkllibpath} -l${_intel_lib} -lmkl_core -lmkl_gnu_thread -ldl -lpthread -lm"
+ _openmplibpath=${PROD_DIR}/compiler/lib/intel64
+ _mkllibs="-L${_mkllibpath} -L${_openmplibpath} -Wl,--no-as-needed \
+ -l${_intel_lib} \
+ -lmkl_intel_thread \
+ -lmkl_core \
+ -liomp5 -ldl -lpthread -lm"
LDFLAGS="${LDFLAGS} -L${_icclibpath}"
+ export MAIN_LDFLAGS="-qopenmp"


if [ $_CC = "icc" ]; then
@@ -73,6 +80,10 @@ build() {
export LD="xild"
export _F77="ifort"
export _FC="ifort"
+ export CFLAGS="-O3 -ipo -qopenmp -parallel -xHost -fp-model strict -qopt-mem-layout-trans=3 -I${MKLROOT}/include"
+ export CXXFLAGS="-O3 -ipo -qopenmp -parallel -xHost -fp-model strict -qopt-mem-layout-trans=3 -I${MKLROOT}/include"
+ export FFLAGS="-O3 -ipo -qopenmp -parallel -xHost -fp-model strict -qopt-mem-layout-trans=3 -I${MKLROOT}/include"
+ export FCFLAGS="-O3 -ipo -qopenmp -parallel -xHost -fp-model strict -qopt-mem-layout-trans=3 -I${MKLROOT}/include"
else
export _F77="gfortran"
export _FC="gfortran"
@@ -87,11 +98,14 @@ build() {
rincludedir=/usr/include/R/ \
rdocdir=/usr/share/doc/R/ \
--with-x \
- --enable-R-shlib \
- --with-blas="${_mkllibs}" \
- --with-lapack \
- F77=${_F77} \
- FC=${_FC} \
+ --with-blas="${_mkllibs}" \
+ --with-lapack \
+ --enable-R-shlib \
+ --enable-memory-profiling \
+ --enable-BLAS-shlib \
+ --enable-openmp \
+ F77=${_F77} \
+ FC=${_FC} \
LIBnn=lib

# Place Intel's basic math library prior to GLIBC libm

jdarch commented on 2015-09-08 11:54

gabx, Intel's basic math library contains an performance-optimized subset of libm. By linking to it before linking to libm some operations might have slightly higher performance, as the call will then be handled by Intel's library. AMD has a similar library: http://developer.amd.com/tools-and-sdks/cpu-development/libm/

gabx commented on 2015-09-06 11:42

For information, what reason behind:
# Place Intel's basic math library prior to GLIBC libm

Thank you

gabx commented on 2015-07-29 14:18

It seems I have a mess with my ICC compiler.
$ makepkg
.....
checking for gcc... icc
checking whether the C compiler works... no
*********************************
$ cat src/R-3.2.1/config.log
............
configure:5941: checking for gcc
configure:5968: result: icc
configure:6197: checking for C compiler version
configure:6206: icc --version >&5
./configure: line 6208: icc: command not found
configure:6217: $? = 127
configure:6206: icc -v >&5
./configure: line 6208: icc: command not found
configure:6217: $? = 127
configure:6206: icc -V >&5
./configure: line 6208: icc: command not found
configure:6217: $? = 127
configure:6206: icc -qversion >&5
./configure: line 6208: icc: command not found
configure:6217: $? = 127
configure:6237: checking whether the C compiler works
configure:6259: icc -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2 -Wl,-O1,--sort-common,--as-needed,-z,relro -L/opt/intel/composerxe/compiler/lib/intel64 conftest.c >&5
./configure: line 6261: icc: command not found
*******************
$ ls /opt/intel
....
drwxr-xr-x 9 root root 4.0K Jul 11 18:51 composer_xe_2015.3.187/
lrwxrwxrwx 1 root root 17 Jul 11 18:37 composerxe -> ./composerxe-2015/
lrwxrwxrwx 1 root root 24 Jul 11 18:37 composerxe-2015 -> ./composer_xe_2015.3.187/
************************
$ ls /opt/intel/composer_xe_2015.3.187/bin/intel64
....
-rwxr-xr-x 1 root root 4.1M Jul 11 18:37 icc*
********************************

Thank you for help

halfhorn commented on 2015-06-27 17:39

@ leonardof

That looks like you have a problem with your mkl installation/configuration.

leonardof commented on 2015-06-04 00:06

I wasn't able to compile this package. Starting build(), I got this message:

/tmp/yaourt-tmp-leonardof/aur-r-mkl/./PKGBUILD: line 62: /opt/intel/mkl/bin/mklvars.sh: Arquivo ou diretório não encontrado

"Arquivo ou diretório não encontrado" means "file or directory not found". That's because the script is in /opt/intel/composer_xe_2015.3.187/mkl/bin/mklvars.sh.

I guess it's not really r-mkl's fault, but I thought you might want to know. Anyway, I created a symlink between the real and the expected "mkl" directory, and at last build took a little longer to fail.

This time I got this message in the start of buid:

/tmp/yaourt-tmp-leonardof/aur-r-mkl/./PKGBUILD: line 69: [: =: esperado operador unário

"esperado operador unário" means "expected unary operator". The compilation went on, and eventually ended with this:

gcc -shared -fopenmp -Wl,-O1,--sort-common,--as-needed,-z,relro -L/opt/intel/composerxe/compiler/lib/intel64 -o libR.so CommandLineArgs.o Rdynload.o Renviron.o RNG.o agrep.o apply.o arithmetic.o array.o attrib.o bind.o builtin.o character.o coerce.o colors.o complex.o connections.o context.o cum.o dcf.o datetime.o debug.o deparse.o devices.o dotcode.o dounzip.o dstruct.o duplicate.o edit.o engine.o envir.o errors.o eval.o format.o gevents.o gram.o gram-ex.o graphics.o grep.o identical.o inlined.o inspect.o internet.o iosupport.o lapack.o list.o localecharset.o logic.o main.o mapply.o match.o memory.o names.o objects.o options.o paste.o platform.o plot.o plot3d.o plotmath.o print.o printarray.o printvector.o printutils.o qsort.o random.o raw.o registration.o relop.o rlocale.o saveload.o scan.o seq.o serialize.o sort.o source.o split.o sprintf.o startup.o subassign.o subscript.o subset.o summary.o sysutils.o times.o unique.o util.o version.o g_alab_her.o g_cntrlify.o g_fontdb.o g_her_glyph.o xxxpr.o `ls ../unix/*.o ../appl/*.o ../nmath/*.o` ../extra/tre/libtre.a -lblas -lgfortran -limf -lm -lquadmath -lreadline -lpcre -llzma -lbz2 -lz -lrt -ldl -limf -lm -licuuc -licui18n
/usr/bin/ld: cannot find -limf
/usr/bin/ld: cannot find -limf
collect2: error: ld returned 1 exit status
Makefile:185: recipe for target 'libR.so' failed
make[3]: *** [libR.so] Error 1
make[3]: Leaving directory '/tmp/yaourt-tmp-leonardof/aur-r-mkl/src/R-3.2.0/src/main'
Makefile:143: recipe for target 'R' failed
make[2]: *** [R] Error 2
make[2]: Leaving directory '/tmp/yaourt-tmp-leonardof/aur-r-mkl/src/R-3.2.0/src/main'
Makefile:28: recipe for target 'R' failed
make[1]: *** [R] Error 1
make[1]: Leaving directory '/tmp/yaourt-tmp-leonardof/aur-r-mkl/src/R-3.2.0/src'
Makefile:59: recipe for target 'R' failed
make: *** [R] Error 1

halfhorn commented on 2015-05-06 08:08

This package is being maintained at https://github.com/m-wells/r-mkl if you would like to submit pull requests and help contribute to the maintenance of this package.

jdarch commented on 2014-12-13 19:52

I will orphan this package.

This package depends on intel-mkl, which I have orphaned as my license is moving towards its end and I have not yet decided if I would take a license for Intel Parallel Studio XE. I suppose someone with a clear future outlook with regard to MKL/Parallel might be able to take over maintenence.

It might also be possible to script use of Intel's compiler, as most people using MKL should have that available in the future.

tetonedge commented on 2014-11-04 03:02

R 3.1.2 was released, please update when you can. Thanks!

setbl commented on 2014-09-13 14:20

jdarch, it's working now, even with parallel studio installed instead of just mkl
rJava is ok

jdarch commented on 2014-09-06 09:31

I believe it might be better for users to create a custom makepkg-icc.conf with appropriate compiler environment settings, a file like that can be called with makepkg --config. That way it is also easy to use the compiler for various other packages.

jdarch commented on 2014-09-06 09:31

I believe it might be better for users to create a custom makepkg-icc.conf with appropriate compiler flags, a file like that can be called with makepkg --config. That way it is also easy to use the compiler for various other packages.

gabx commented on 2014-09-02 07:39

some of us are using the Intel compiler (IC). As I don't think it is worth having two r-mkl AUR packages, would you mind adding something like that in your PKGBUILD to enable IC.

at the begining:

# _CC="icc" # uncomment to build with the Intel compiler

then below the # build package:
if [ $_CC = "icc" ]; then
export CC="icc"
export CXX="icpc"
export AR="xiar"
export LD="xild"
fi

Thank you

jdarch commented on 2014-08-30 12:28

I have added a line to change R's config script to look in Makeconf. setbl, this should resolve your package building issue I suppose. Please post comments here if this change breaks something.

jdarch commented on 2014-08-30 10:48

rJava takes build flags from 'R CMD config --ldflags'. Apparently the 'config' script does not take LDFLAGS from R's Makeconf (which should include the path to libimf), but from the environment. Setting the environment variable should enable you to complete the build of rJava. I have no clue as to the reasons for the 'config' script not including LDFLAGS from Makeconf but from the environment (while taking the other parameters from Makeconf, not from the environment).

I might just include a patch for the config script in a new PKG release.

jdarch commented on 2014-08-28 20:38

You might need to look at the library configuration in /etc/R/Makeconf /etc/R/javaconf and the other config files, I had added in -limf before -lm and made some other modifications, I might need to look at the PKGBUILD to create the appropriate LD-PATH settingse etc automatically. You can try if adding the Intel lib path to JAVA_LD_LIBRARY_PATH in javaconf fixes things

setbl commented on 2014-08-24 13:40

after successfully installing r-mkl, I cannot install.packages('rJava')

error is /usr/bin/ld: cannot find -limf

which is missing in the system but is an mkl library

tklee commented on 2014-07-15 02:22

Sorry, I forgot to mention I was using icc.

tklee commented on 2014-07-15 02:21

FYI, I had to add -parallel in LDFLAGS in PKGBULID to compile.

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

gabx commented on 2014-04-21 11:15

During the last part of building, the test part, I have one error when testing mgcv.Rcheck:

Intel MKL FATAL ERROR: Cannot load libmkl_avx.so or libmkl_def.so.

R-mkl still built and is not broken. This error is quite weird as :
1 - $ cat /etc/ld.so.confd/intel-mkl
/opt/intel/composer_xe_2013_sp1.2.144/mkl/lib/intel64
/opt/intel/composer_xe_2013_sp1.2.144/compiler/lib/intel64

2- In PKGBUILD ${LD_LIBRARY_PATH} is correctly set and path to lib is OK.

gabx commented on 2014-04-21 11:05

FYI, your package build fine with these optimization flags:
export CFLAGS="-Wall -Ofast -funsafe-loop-optimizations -ipo -openmp -xHost -Wno-fstrict-aliasing"
export CXXFLAGS="-Wall -Ofast -ipo -funsafe-loop-optimizations -openmp -xHost -Wno-fstrict-aliasing -march=native -flto"

Then, I use the ICC and ICPC compiler. I need each time to hack your PKGBUILD (not a great deal thought). Would you mind adding something like this:

# Build the package using the icc compiler
_CC="icc"
if [ $_CC = "icc" ]; then
export CC="icc"
export CXX="icpc"
export AR="xiar"
export LD="xild"
fi

I use this as LDFLAGS:

export LDFLAGS="-L${_icclibpath} -${CXXFLAGS} -shared-intel"

Last, when building R, R-mkl and R-studio, I remarked my home Rprofile.r is screawing the build. So I add these lines too and have a cleaner build:

# unset user Rprofile.r variable for building
if [ -n $R_PROFILE_USER ]; then
unset R_PROFILE_USER
fi


TY for your package.

gabx commented on 2014-04-01 13:04

TY for your package.
Following Intel resources article here: http://software.intel.com/en-us/articles/build-r-301-with-intel-c-compiler-and-intel-mkl-on-linux
I added
$ export CFLAGS="-O3 -ipo -openmp -xHost"
$ export CXXFLAGS="-O3 -ipo -openmp -xHost"
to your BKPGBUILD and R built fine.

jdarch commented on 2014-01-03 14:32

libimf is linked in now, this should usually speed up some mathematical operations.

jdarch commented on 2013-12-24 10:05

zeltak, I am not aware of any issues. You should be able to build 'lme4', it's prerequisites 'Matrix' and 'lattice' should be available. ((lme4 is working fine here) Note Matrix has a capital 'M'. The procedure to update packages is described in the R manual: http://cran.r-project.org/doc/manuals/R-admin.html#Updating-packages .

jdarch commented on 2013-12-23 14:15

zeltak, I am not aware of any issues. You should be able to build 'lme4', it's prerequisites 'Matrix' and 'lattice' should be available. Note Matrix has a capital 'M'.

zeltak commented on 2013-12-22 12:48

thx you for this great package. i have a neewb Q. i need to use lme4 in my scripts. i see after installing r-mkl there isnt matrix 1.1 package which latest lme4 needs. i installed in through R. Does that mean i wont get mkl using lme4 since the matrix package wasnt compiled with mkl? is there a way to update matrix to latest release?

thanks alot again

Z

aberkoke commented on 2013-10-24 13:11

jdarch: Ok, it is done!

jdarch commented on 2013-10-24 12:15

aberkoke: that's right, the icu-package (icu: International Components for Unicode library) has moved from version 51.x to 52.x 12 days ago. You had built r-mkl with version 51.x, so now I cannot find the library anymore, as R is looking for libicu*.so.51, but the libs are now called libicu*.so.52.

Solution: build r-mkl again and it will work again.

jdarch commented on 2013-10-24 12:15

aberkoke: that's right, the icu-package (icu: International Components for Unicode library) has moved from version 51.x to 52.x 12 days ago. You had built r-mkl with version 51.x, so now I cannot find the library anymore, as R is looking for libicu*.so.51 I think, but the libs are now called libicu*.so.52.

Solution: build r-mkl again and it will work again.

jdarch commented on 2013-10-24 12:14

aberkoke: that's right, the icu-package (icu: International Components for Unicode library) has moved from version 51.x to 52.x 12 days ago. You had built r-mkl with version 51.x, so now I cannot find the library anymore, as R is looking for libicu*.so.51 I think, but the libs are now called libicu*.so.52.

Solution: build r-mkl again and it will work again.

jdarch commented on 2013-10-24 12:11

aberkoke: that's right, the icu-package (icu: International Components for Unicode library) has moved from version 51.x to 52.x 12 days ago. You had built r-mkl with version 51.x, so now I cannot find the library anymore, as R is looking for libicuuc.so.51 I think, but the lib is now called libicuuc.so.52.

Solution: build r-mkl again and it will work again.

aberkoke commented on 2013-10-24 10:50

R doesn't work after latest upgrades. There is a problem with package "icu" or "lib32-icu".

[eduardo@manjaro-linux lib]$ R
/usr/lib64/R/bin/exec/R: error while loading shared libraries: libicuuc.so.51: cannot open shared object file: No such file or directory

jdarch commented on 2013-10-22 02:31

To speed up some more commonly used basic math functions (e.g. log,root,trigonometric) I have tested linking against Intel's 'libimf' (included in intel-mkl) and AMD's 'libamdlibm' (in AUR: amdlibm). Use of amdlibm resulted in substantial speedups compared to libm-218, libimf also showed speedups, but much less substantial (at least on the (AMD) CPU I had used for testing). For both libraries some functions showed slight slowdowns compared to libm as well. It would be great to get some more input from users with other processors to decide if linking against libimf or libamdlibm by default makes sense. You can try out the libraries by preloading them (LD_PRELOAD).

jdarch commented on 2013-10-19 13:45

To speed up some more commonly used basic math functions (log,root,trigonometric) I have tested linking against intel's libimf (included in intel-mkl) and libamdlibm (in AUR: amdlibm). Use of amdlibm resulted in substantial speedups compared to libm-218, libimf also, but much lesson the (AMD) CPU I had used for testing), for both libraries some functions showed slight slowdowns compared to libm as well. It would be great to get some more input from users with other processors to decide if linking against libimf or libamdlibm by default makes sense. You can try out the libraries by preloading them (LD_PRELOAD).

jdarch commented on 2013-10-04 07:23

aberkoke, I have never compared the performance of R compiled with Intel's compilers to R compiled with the GNU compiler collection. I would not expect a substantial difference in most cases, but that might vary dependant on the type of CPU and what instructions R needs to perform.

But if you could try it out, that would be great! It should be possible to make different versions with different compilers and compiler flags by playing with the CC, CFLAGS etc. environment variables before building the package.

aberkoke commented on 2013-10-03 12:11

Thanks for the maintenance of the pagacke! What do you think about compile R with intel icc? better performance?

jdarch commented on 2013-09-25 10:22

Updated to 3.0.2. If there are file conflicts because of updated packages, just delete the 3.0.1 files. Please inform me of any bugs.

jdarch commented on 2013-08-05 05:53

Updated to 3.0.1

matmo commented on 2012-10-17 09:02

Updated to 2.15.1, I am not sure if I provided the MKL_ROOT correctly, comments welcome

Shirakawasuna commented on 2011-07-10 09:44

CRAN makes it difficult to allow a package to stay slightly out of date (I can't devote the time necessary) and it's much easier to use R's built-in installation program, so I'm disowning this package. Sorry!

Shirakawasuna commented on 2011-06-26 00:40

Updated to 2.13.0

giniu commented on 2011-02-14 09:41

I'm removing and disowning all my -mkl packages, I've lost interest in this library after trying to use it with numpy for 7 months and failing miserably - this isn't new issue and I'm not alone, take a look at date of this still unsolved problem ( http://matt.eifelle.com/2008/11/03/i-used-the-latest-mkl-with-numpy-and/ ) - this is only information I got when asking on numpy mailing list about the issue I'm having. I decided to use ATLAS instead of MKL everywhere I can, if you want to, go on and adopt the package. MKL is nice library, but I think it costs too much time to get it working.

giniu commented on 2010-12-07 16:12

needs rebuild because of xz 5.0 update

giniu commented on 2010-11-10 21:09

updated to MKL 10.3

giniu commented on 2010-07-30 19:19

hopefully fixed linking MKL on 32bit machines. If it worked for someone before there is no need to update, so I'm not bumping the version.

giniu commented on 2010-05-06 00:11

I haven't tested it yet, it's mostly package from extra modified to use Intel MKL, it can give quite huge speed-up on some calculations (like 6 times faster!), but remember you need license for Intel MKL. Check http://www.r-bloggers.com/compiling-64-bit-r-2-10-1-with-mkl-in-linux/ for info that was used to setup this package.