Package Details: r-mkl 4.2.1-1

Git Clone URL: https://aur.archlinux.org/r-mkl.git (read-only, click to copy)
Package Base: r-mkl
Description: Language and environment for statistical computing and graphics, linked to the Intel(R) MKL.
Upstream URL: http://www.r-project.org/
Keywords: hpc mathematics modelling r statistics
Licenses: GPL
Conflicts: microsoft-r-open, r
Provides: r
Submitter: giniu
Maintainer: alexanderp
Last Packager: alexanderp
Votes: 22
Popularity: 0.070173
First Submitted: 2010-05-06 00:10 (UTC)
Last Updated: 2022-06-25 07:27 (UTC)

Latest Comments

burgerga commented on 2021-07-27 12:20 (UTC)

@alexanderp Yeah, I see your point. Could you just error the installation if it is not set? Because it took me quite some time to figure out that the linker errors I got from install.packages in R were caused MKLROOT not being defined, and that would save other people the trouble.

alexanderp commented on 2021-07-14 18:37 (UTC)

@burgerga , I'm a bit wary of hardcoding this in the PKGBUILD since it will be introducing a dependency on the specific file from intel-mkl existing in that path.

I've checked other packages which depend on intel-mkl and they are not sourcing the script manually either.

burgerga commented on 2021-07-12 10:38 (UTC)

@alexanderp I contacted the intel-mkl maintainer, and he suggested that if MKLROOT is not yet set, to source /etc/profile.d/intel-mkl.sh in the r-mkl PKGBUILD

burgerga commented on 2021-07-12 07:21 (UTC) (edited on 2021-07-12 07:29 (UTC) by burgerga)

@alexanderp Figured it out! intel-mkl installs /etc/profile.d/intel-mkl.sh which sets MKLROOT, but doesn't source it, so MKLROOT is only set after the next reboot.

EDIT: I see that are messages crossed. I'll ask the maintainer of intel-mkl to pick this up.

alexanderp commented on 2021-07-12 07:15 (UTC)

@burgerga

$ cat /etc/profile.d/intel-mkl.sh 
export MKLROOT=/opt/intel/mkl

owned by:

$ pacman -Qo /etc/profile.d/intel-mkl.sh 
/etc/profile.d/intel-mkl.sh is owned by intel-mkl 2020.4.304-1

burgerga commented on 2021-07-12 07:09 (UTC) (edited on 2021-07-12 07:10 (UTC) by burgerga)

@alexanderp Ah, yes you're right, however the contents of that file are:

#!/bin/sh
#
# This little script pretends to be mklvars.sh but actually just exports some variables
# to directories precisely where Arch installs them. No point shipping the original
# mklvars.sh which wrongly guesses all the paths.

export "LD_LIBRARY_PATH=/opt/intel/mkl/lib/intel64_lin:${LD_LIBRARY_PATH}"
export "LIBRARY_PATH=/opt/intel/mkl/lib/intel64_lin:${LIBRARY_PATH}"
export "NLSPATH=/opt/intel/mkl/lib/intel64_lin/locale/%l_%t/%N:${NLSPATH}"
export "CPATH=/opt/intel/mkl/include:${CPATH}"
export "PKG_CONFIG_PATH=/usr/lib/pkgconfig:${PKG_CONFIG_PATH}"

So it doesn't set MKLROOT (I don't know if the original did?), so how is MKLROOT set on your system?

EDIT: Maybe intel-mkl should set MKLROOT though, that would be more logical than setting it in r-mkl

alexanderp commented on 2021-07-11 10:50 (UTC)

@burgerga

Cannot reproduce this in my build system. In fact, mklvars.sh is still here:

pacman -Qo mklvars.sh
/usr/bin/mklvars.sh is owned by intel-mkl 2020.4.304-1

burgerga commented on 2021-07-06 23:01 (UTC) (edited on 2021-07-06 23:02 (UTC) by burgerga)

@alexanderp I'm getting the same issue as @jalapeno

/usr/bin/ld: cannot find -lmkl_gf_lp64
/usr/bin/ld: cannot find -lmkl_gnu_thread
/usr/bin/ld: cannot find -lmkl_core
collect2: error: ld returned 1 exit status

The problem in my case is that MKLROOT was not set during installation so ${MKLROOT}/lib/intel64 becomes /lib/intel64 which is used as -L flag in the BLAS_LIBS makevar in /usr/lib/R/etc/Makeconf, and then of course when we try to compile packages, the linker can't find the shared libraries.

I think the issue might be that intel-mkl does not come with mklvars.sh anymore. There is only mkl_link_tool in /opt/intel/mkl/bin and if you run it with either the -env or the -interactive option you can see that it assumes MKLROOT is already set...

sgrubsmyon commented on 2021-05-05 14:40 (UTC)

@Humble_Panda Yes, indeed. Removing and reinstalling (recompiling) the r-mkl package helped in my case.

Humble_Panda commented on 2021-02-08 08:27 (UTC)

Anyone else getting a broken R installation after one of the last updates? libicuuc.so.67 isn't on the system anymore...

alexanderp commented on 2021-01-20 14:22 (UTC)

@LuisDamiano, in my opinion, distributing a binary of this package defeats the purpose of the additional CPU performance optimizations obtained by compiling on a target system.

Svenstaro commented on 2021-01-19 08:09 (UTC)

@LuisDamiano you could talk to the maintainers of the r package whether they'd be interested in pulling this in.

LuisDamiano commented on 2021-01-18 16:44 (UTC)

Thanks for the great work! It takes quite a bit to compile locally, would it be possible to get r-mkl added to the Extra official repo? Having the binaries would be quite useful.

k07k454n commented on 2020-11-24 18:30 (UTC) (edited on 2020-11-24 18:33 (UTC) by k07k454n)

Had issues for 4.0.2 and 4.0.3 like this during build:

Error: package or namespace load failed for ‘nnet’ in dyn.load(file, DLLpath = DLLpath, ...):                                                                                                                                                                                     
 unable to load shared object '/home/user/aur/r-mkl/src/R-4.0.3/library/nnet/libs/nnet.so':                                                                                                                                                                                       
  /home/user/aur/r-mkl/src/R-4.0.3/library/nnet/libs/nnet.so: undefined symbol: _ZGVbN2v_exp                                                                                                                                                                                      
Error: loading failed 
** testing if installed package can be loaded                                                                                            
Error: package or namespace load failed for ‘MASS’ in dyn.load(file, DLLpath = DLLpath, ...):                                                      
 unable to load shared object '/home/user/aur/r-mkl/src/R-4.0.3/library/MASS/libs/MASS.so':                                                        
  /home/user/aur/r-mkl/src/R-4.0.3/library/MASS/libs/MASS.so: undefined symbol: _ZGVbN2v_log                                                       
Error: loading failed 

..so to build and install successfully had to first do 'export SHLIB_LDFLAGS=-lmvec' before makepkg

alexanderp commented on 2020-08-24 19:12 (UTC)

@jalapeno, if intel-mkl was updated, try recompiling the package.

jalapeno commented on 2020-08-20 19:55 (UTC)

When attempting to install a package in r-mkl, I get this error:

install.packages("mnormt")
[truncated]
/usr/bin/ld: cannot find -lmkl_gf_lp64
/usr/bin/ld: cannot find -lmkl_gnu_thread
/usr/bin/ld: cannot find -lmkl_core
collect2: error: ld returned 1 exit status
make: *** [/usr/share/R//make/shlib.mk:6: tmvnsim.so] Error 1
ERROR: compilation failed for package ‘tmvnsim’

I was unable to find a solution here, but managed to just copy lmkl_gf_lp64.so lmkl_gf_thread and lmkl_core.so' from/opt/intel/mkl/lib/intel64to/usr/lib/R/lib`.

Is there some other way that this ought to be done? Or, is this the only work-around?

tealeaf commented on 2020-07-26 19:51 (UTC)

As a follow-up to my previous comment: downgrading to intel-mkl-2020.1.217-6 resolved this for the moment.

tealeaf commented on 2020-07-26 15:28 (UTC)

Not sure if this belongs here, in intel-mkl, or elsewhere, but I'm having a problem running R-INLA under this on a new machine. I can install with:

install.packages("INLA", repos=c(getOption("repos"), INLA="https://inla.r-inla-download.org/R/testing"), dep=TRUE)

as normal, but running:

library(INLA)
inla.pardiso.check()

I get:

/home/joss/.R/packages/INLA/bin/linux/64bit/inla: symbol lookup error: /opt/intel/mkl/lib/intel64/libmkl_gf_lp64.so: undefined symbol: mkl_lapack_scombssq
Error in system(paste(shQuote(inla.call.no.remote()), "-m pardiso"), intern = TRUE) : error in running command

The strange thing is that this is working on my old machine with an almost identical setup.

sxyzy1016 commented on 2020-06-26 10:32 (UTC) (edited on 2020-06-27 02:08 (UTC) by sxyzy1016)

using icc to build it by uncomment the line # _CC="icc" and get:

...
icc -I../../src/extra -I/usr/include/tirpc -I. -I../../src/include -I../../src/include  -D_FORTIFY_SOURCE=2 -I../../src/nmath -DHAVE_CONFIG_H   -fopenmp -fpic  -O3 -fPIC -m64 -march=native -fp-model precise -fp-model source -I/opt/intel/mkl/include  -c arithmetic.c -o arithmetic.o
arithmetic.c(61): warning #274: declaration is not visible outside of function
  int matherr(struct exception *exc)
                     ^

arithmetic.c(63): error: pointer to incomplete class type is not allowed
      switch (exc->type) {
              ^

arithmetic.c(64): error: identifier "DOMAIN" is undefined
      case DOMAIN:
           ^

arithmetic.c(65): error: identifier "SING" is undefined
      case SING:
           ^

arithmetic.c(68): error: identifier "OVERFLOW" is undefined
      case OVERFLOW:
           ^

arithmetic.c(71): error: identifier "UNDERFLOW" is undefined
      case UNDERFLOW:
           ^

arithmetic.c(72): error: pointer to incomplete class type is not allowed
    exc->retval = 0.0;
    ^

compilation aborted for arithmetic.c (code 2)
...

in build(). EDIT: according to this, use

sed -i '/^#define HAVE_MATHERR 1/d' src/include/config.h

between configure and make will make it work.

Svenstaro commented on 2020-06-15 17:22 (UTC)

Alright but can you check the new intel-mkl that blue includes a shim script for mklvars.sh? It should work.

alexanderp commented on 2020-06-15 10:51 (UTC) (edited on 2020-06-15 10:52 (UTC) by alexanderp)

Hi @Svenstaro. No reason, other than wanting to fix r-mkl as quickly as possible after the move of intel-mkl to [Community]. I read the discussions on not including the original MKL scripts on the basis of standardization, so I made the decision to maintain compatibility locally.

Anyway, I copied the mklvars.sh script from upstream, therefore it should work for any package that depends on it.

Also, thank you for bringing intel-mkl to [Community]. Hopefully we'll get smoother upgrades and less incompatibilities this way.

Svenstaro commented on 2020-06-14 22:51 (UTC)

Hey, I'm the maintainer of the intel-mkl package and I just stumbled upon this pacakage right here. I'm trying to add a mklvars.sh to the [community] package that works for most people.

I'm curious: Why didn't you provide a patch for this on our bug tracker? Currently, your patch only works for this package but maybe other people would also be happy to benefit from the added mklvars.sh.

alexanderp commented on 2020-04-07 21:43 (UTC)

Update: I've added logic that allows this package to compile with both the AUR and Community versions of intel-mkl.

alexanderp commented on 2020-04-07 20:29 (UTC)

@mys_721tx, the intel-mkl package in Community is a mess. It's trying to force some rules/opinions which have obviously broken the software which depend on it. It's missing a lot of setup scripts from the original package on AUR and has rearranged most libraries and files.

I suggest to keep using intel-mkl from AUR, until the Community version is fixed.

mys_721tx commented on 2020-04-06 23:54 (UTC)

@alexanderp intel-mkl currently shipped in [Community] does not include mklvars.sh, which is required by PKGBUILD.

alexanderp commented on 2020-03-07 23:52 (UTC)

@Nexilim, no need for special Makevars file. R should already be using the correct libraries and headers during package compilation.

Nexilim commented on 2020-03-07 23:28 (UTC)

Could anyone please share their Makevars file with the correct flags and routes to MKL? Thanks!

alexanderp commented on 2020-02-18 08:40 (UTC)

@petronny, that's not a build error. That's an error during the check phase and it doesn't affect the package, nor R usage.

petronny commented on 2020-02-18 04:54 (UTC)

Hi, now I get

Error in texi2dvi(file = file, pdf = TRUE, clean = clean, quiet = quiet,  : 
  pdflatex is not available

when building this package.

Should we list texlive in makedepends?

alexanderp commented on 2020-02-17 18:36 (UTC) (edited on 2020-02-17 18:38 (UTC) by alexanderp)

@laborat, the recent (two days old) community/intel-mkl package lacks a lot of content from the split package.

Please keep on using aur/intel-mkl as part of aur/intel-parallel-studio-xe until the relevant scripts are ported to community.

Also, as a general note, those with Ryzen processors could obtain even better performance by setting an environment variable. Please see https://www.reddit.com/r/MachineLearning/comments/f2pbvz/discussion_workaround_for_mkl_on_amd/

laborat commented on 2020-02-17 17:42 (UTC)

The recent update to r-mkl appears to have an issue:

/home/user/.cache/yay/r-mkl/PKGBUILD: line 88: /opt/intel/mkl/bin/mklvars.sh: No such file or directory

Indeed, my /opt/intel/mkl only has 'include' and 'lib'. Missing dependency? community/intel-mkl is at its latest version, 2020.0.166-3

petronny commented on 2019-10-17 05:21 (UTC) (edited on 2019-10-17 05:24 (UTC) by petronny)

@xia0er R uses R-package/src/Makevars instead of the system Makevars when building packages. I find this when I try to build r-mxnet.

I can't recall exactly but I think there is a way to set the Makevars in userspace by editing something like ~/.R/Makevars.

Also someone filed an issue on arch4edu about that the prebuilt binary needs rebuild against the latest mkl. I'm working on it.

xia0er commented on 2019-10-16 20:09 (UTC)

My issue is fixed by editing /etc/R/Makeconf: FCLIBS_XTRA = -L/opt/intel/lib

Not sure why this is still needed, as I can see that /etc/ld.so.conf.d/intel-common-libs.conf has /opt/intel/lib included. I have also tried to set the environment variable export LD_LIBRARY_PATH=-L/opt/intel/lib before starting R, but it doesn't fix the issue.

Hope this helps others with similar issues.

alexanderp commented on 2019-10-15 21:58 (UTC)

@xia0er, looks like your system (container) might be broken. It's considered bad practice to manually manage software inside the container. Instead, recreate your base image.

xia0er commented on 2019-10-15 18:52 (UTC)

@alexanderp The docker image is based on archlinux/base and I update all packages to the latest version with pacman -Syyu before download and install r-mkl with this PKGBUILD (also tried @petronny's binary package) in my own Dockerfile. After building the image and run it in a container, r-mkl works fine as far as I can see, but fails when installing classInt (as a dependency for the package sf). I also tried installing the r packages in the Dockerfile, but it fails in the building process with the same error. Thanks for your help!

alexanderp commented on 2019-10-15 07:52 (UTC)

@xia0er, I guess the first question is how long ago the docker container was built and whether you updated software inside the container.

xia0er commented on 2019-10-15 05:24 (UTC)

Anyone experiencing issue when installing the classInt package on r-mkl? I am getting a strange error on an otherwise fully functional r-mkl installation:

... gcc -shared -L/usr/lib64/R/lib -Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now -o classInt.so fish1.o init.o -lgfortran -limf -lm -lquadmath -L/usr/lib64/R/lib -lR /usr/sbin/ld: cannot find -limf collect2: error: ld returned 1 exit status make: *** [/usr/share/R//make/shlib.mk:6: classInt.so] Error 1 ERROR: compilation failed for package ‘classInt’ ...

But libimf.so is present in the /opt/intel/lib directory.

Besides, it also complains missing include dirs in a warning message, but, oddly, pointing to 2019.4.243

gfortran -fno-optimize-sibling-calls -fpic -m64 -I/opt/intel/compilers_and_libraries_2019.4.243/linux/mkl/include -c fish1.f -o fish1.o f951: Warning: Nonexistent include directory ‘/opt/intel/compilers_and_libraries_2019.4.243/linux/mkl/include’ [-Wmissing-include-dirs] fish1.f:100:72:

100 | DO 10 I=1,M | 1 Warning: Fortran 2018 deleted feature: Shared DO termination label 10 at (1) fish1.f:132:72:

132 | 40 IWORK(I,1)=1 | 1 Warning: Fortran 2018 deleted feature: DO termination statement which is not END DO or CONTINUE with label 40 at (1)

The classInt package installs successfully on a regular (non-mkl) R installation.

This happens when running r-mkl on an archlinux docker container, so there is no contamination from an earlier installation of mkl etc.

I appreciate it if anyone can help shed light on what may be happening here. Thanks!

The full stdout with error message can be found at https://gist.github.com/lmwang9527/48386437de1574aac45cb27725f129c7

alexanderp commented on 2019-07-26 07:45 (UTC)

Great @petronny. Thanks for your effort.

petronny commented on 2019-07-26 07:40 (UTC) (edited on 2019-07-26 07:41 (UTC) by petronny)

Hi, I provide a pre-built binary of this package at arch4edu.
Also please vote at this issue if you want more pre-built R packages.

petronny commented on 2019-07-24 07:06 (UTC) (edited on 2019-07-24 07:06 (UTC) by petronny)

Every time Intel MKL gets updated, compilation of R with icc needs to be adapted.

Actually I can deal with that, I can provide a well-built binary with every icc or r-mkl update. But I'll use gcc then since there is no gain when using icc.

alexanderp commented on 2019-07-24 06:40 (UTC) (edited on 2019-07-24 06:41 (UTC) by alexanderp)

Hi @petronny.

Every time Intel MKL gets updated, compilation of R with icc needs to be adapted.

I measured no gain when using icc, therefore this package defaults to gcc.

See some of my benchmarks here: https://github.com/alexisph/high_performance_r

petronny commented on 2019-07-23 07:24 (UTC)

And is building with gcc the recommend way by the official R group to build with MKL support?
If so I can give up building with icc and using gcc now.

petronny commented on 2019-07-23 07:21 (UTC) (edited on 2019-07-23 07:21 (UTC) by petronny)

Hi, thanks for maintaining this package.
Could you help with building with icc?
I've un-comment the line _CC="icc" but I get errors:

icc -I../../src/extra -I/usr/include/tirpc -I. -I../../src/include -I../../src/include  -D_FORTIFY_SOURCE=2 -I../../src/nmath -DHAVE_CONFIG_H   -fopenmp -fpic  -O3 -fPIC -m64 -march=native -fp-model precise -fp-model source -I/opt/intel/compilers_and_libraries_2019.4.243/li
nux/mkl/include  -c envir.c -o envir.o
arithmetic.c(59): warning #274: declaration is not visible outside of function
  int matherr(struct exception *exc)
                     ^

arithmetic.c(61): error: pointer to incomplete class type is not allowed
      switch (exc->type) {
              ^

arithmetic.c(62): error: identifier "DOMAIN" is undefined
      case DOMAIN:
           ^

arithmetic.c(63): error: identifier "SING" is undefined
      case SING:
           ^

arithmetic.c(66): error: identifier "OVERFLOW" is undefined
      case OVERFLOW:
           ^

arithmetic.c(69): error: identifier "UNDERFLOW" is undefined
      case UNDERFLOW:
           ^

arithmetic.c(70): error: pointer to incomplete class type is not allowed
        exc->retval = 0.0;
        ^

icc -I../../src/extra -I/usr/include/tirpc -I. -I../../src/include -I../../src/include  -D_FORTIFY_SOURCE=2 -I../../src/nmath -DHAVE_CONFIG_H   -fopenmp -fpic  -O3 -fPIC -m64 -march=native -fp-model precise -fp-model source -I/opt/intel/compilers_and_libraries_2019.4.243/li
nux/mkl/include  -c errors.c -o errors.o
icc -I../../src/extra -I/usr/include/tirpc -I. -I../../src/include -I../../src/include  -D_FORTIFY_SOURCE=2 -I../../src/nmath -DHAVE_CONFIG_H   -fopenmp -fpic  -O3 -fPIC -m64 -march=native -fp-model precise -fp-model source -I/opt/intel/compilers_and_libraries_2019.4.243/li
nux/mkl/include  -c eval.c -o eval.o
icc -I../../src/extra -I/usr/include/tirpc -I. -I../../src/include -I../../src/include  -D_FORTIFY_SOURCE=2 -I../../src/nmath -DHAVE_CONFIG_H   -fopenmp -fpic  -O3 -fPIC -m64 -march=native -fp-model precise -fp-model source -I/opt/intel/compilers_and_libraries_2019.4.243/li
nux/mkl/include  -c format.c -o format.o
compilation aborted for arithmetic.c (code 2)
make[3]: *** [../../Makeconf:124: arithmetic.o] Error 2
make[3]: *** Waiting for unfinished jobs....
make[3]: Leaving directory '/build/r-mkl/src/R-3.6.1/src/main'
make[2]: *** [Makefile:135: R] Error 2
make[2]: Leaving directory '/build/r-mkl/src/R-3.6.1/src/main'
make[1]: *** [Makefile:28: R] Error 1
make[1]: Leaving directory '/build/r-mkl/src/R-3.6.1/src'
make: *** [Makefile:61: R] Error 1
==> ERROR: A failure occurred in build().

blazko commented on 2019-07-15 07:40 (UTC)

Is anyone else facing validity checks problem with parallel_studio_xe?

==> Validating source files with sha256sums...
    parallel_studio_xe_2019_update4_cluster_edition.tgz ... FAILED
    intel_compilers.sh ... Passed
    intel_vtune-amplifier.sh ... Passed
    intel_advisor.sh ... Passed
    intel_inspector.sh ... Passed
    intel-composer.install ... Passed
    intel-common-libs.conf ... Passed
    intel-fortran.conf ... Passed
    intel-openmp.conf ... Passed
    intel-mkl.conf ... Passed
    intel-mpi.conf ... Passed
    intel-ipp.conf ... Passed
    intel-tbb.conf ... Passed
    intel-mkl.sh ... Passed
    intel-mkl.install ... Passed
    intel-mkl-th.conf ... Passed
    intel-tbb.install ... Passed
    EULA.txt ... Passed
==> ERROR: One or more files did not pass the validity check!

alexanderp commented on 2019-05-17 11:46 (UTC)

Thanks for the report @blazko. To be honest, those numbers look strange to me... Did you consider reporting this to the Intel MKL forums? (https://software.intel.com/en-us/forums/intel-math-kernel-library)

By the way, have you done any benchmark comparisons between the versions?

blazko commented on 2019-05-17 11:40 (UTC)

@alexanderp I sorted this out. For a 4 cores 8 threads CPU I should set export MKL_NUM_THREADS=32 on my laptop (instead of 8) and export MKL_NUM_THREADS=128 on the xeon (instead of 32),

After this they all work at max speeds and resources.

alexanderp commented on 2019-05-07 10:59 (UTC)

@blazko, Not sure... It seems that the way GNU OpenMP utilizes cores/threads is different. Just for reference, I am getting the same behaviour when using the microsoft-r-open package.

blazko commented on 2019-05-07 08:49 (UTC)

@alexanderp thanks for your tests - i'm running a bigger batch of those sims right now, and I would avoid stopping them.

Your test clearly shows, that performancewise OpenMP is better. Is there a reason we can't run that on 100%?

alexanderp commented on 2019-05-06 20:15 (UTC)

@blazko, I modified your code as such:

library(simr)
dataf <- read.csv("Rdataframe.csv", stringsAsFactors = F)
ns = 500
ss<-1
m1 <- lmer(scc ~ naC + (naC|subj), dataf)
summary(m1)
fixef(m1)["naC"] <- -0.15
set.seed(ss)
system.time(
  p1 <- powerCurve(m1, along="subj", nsim=100, breaks = seq(20, 100, 20))
)

These were the results:

R 3.5.3 with Intel threading:

  • all cores 100% in top
  • user 1015.352, system 73.983, elapsed 206.349

R 3.6.0 with GNU OpenMP:

  • half of the cores active in top
  • user 245.528, system 3.107, elapsed 181.824

Please run this on your side as well and report back.

alexanderp commented on 2019-05-06 19:57 (UTC)

@mys_721tx, I've never had to source mklvars.sh manually, since it's loaded by profile.d on login.

mys_721tx commented on 2019-05-06 19:36 (UTC)

@alexanderpLD_LIBRARY_PATH and LIBRARY_PATH are not captured in Makeconf. Therefore /opt/intel/mkl/bin/mklvars.sh must be sourced before building any package that uses limf.

alexanderp commented on 2019-05-06 19:02 (UTC) (edited on 2019-05-06 19:02 (UTC) by alexanderp)

@mys_721tx,

mys_721tx commented on 2019-05-06 18:51 (UTC)

@alexanderp Could you post your Makeconf?

# etc/Makeconf.  Generated from Makeconf.in by configure.
#
# ${R_HOME}/etc/Makeconf
#
# R was configured using the following call
# (not including env. vars and site configuration)
# 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' '--with-blas= -L/opt/intel/compilers_and_libraries_2019.3.199/linux/mkl/lib/intel64       -Wl,--no-as-needed       -lmkl_gf_lp64       -lmkl_gnu_thread       -lmkl_core       -lgomp       -lpthread       -limf -lm       -ldl' '--with-lapack' '--enable-R-shlib' 'LIBnn=lib' 'PKG_CONFIG_PATH=/opt/intel/compilers_and_libraries_2019.3.199/linux/mkl/bin/pkgconfig' 'CC=gcc' 'CFLAGS= -m64 -I/opt/intel/compilers_and_libraries_2019.3.199/linux/mkl/include -march=x86-64 -mtune=generic -O2 -pipe -fno-plt' 'LDFLAGS=-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now' 'CPPFLAGS=-D_FORTIFY_SOURCE=2' 'FC=gfortran' 'FCFLAGS= -m64 -I/opt/intel/compilers_and_libraries_2019.3.199/linux/mkl/include ' 'CXX=g++' 'CXXFLAGS= -m64 -I/opt/intel/compilers_and_libraries_2019.3.199/linux/mkl/include -march=x86-64 -mtune=generic -O2 -pipe -fno-plt'

## This fails if it contains spaces, or if it is quoted
include $(R_SHARE_DIR)/make/vars.mk

AR = ar
BLAS_LIBS =  -L/opt/intel/compilers_and_libraries_2019.3.199/linux/mkl/lib/intel64       -Wl,--no-as-needed       -lmkl_gf_lp64       -lmkl_gnu_thread       -lmkl_core       -lgomp       -lpthread       -limf -lm       -ldl
C_VISIBILITY = -fvisibility=hidden
CC = gcc
CFLAGS =  -m64 -I/opt/intel/compilers_and_libraries_2019.3.199/linux/mkl/include -march=x86-64 -mtune=generic -O2 -pipe -fno-plt $(LTO)
CPICFLAGS = -fpic
CPPFLAGS = -D_FORTIFY_SOURCE=2
CXX = g++ -std=gnu++11
CXXCPP = $(CXX) -E
CXXFLAGS =  -m64 -I/opt/intel/compilers_and_libraries_2019.3.199/linux/mkl/include -march=x86-64 -mtune=generic -O2 -pipe -fno-plt $(LTO)
CXXPICFLAGS = -fpic
CXX98 = g++
CXX98FLAGS =  -m64 -I/opt/intel/compilers_and_libraries_2019.3.199/linux/mkl/include -march=x86-64 -mtune=generic -O2 -pipe -fno-plt $(LTO)
CXX98PICFLAGS = -fpic
CXX98STD = -std=gnu++98
CXX11 = g++
CXX11FLAGS =  -m64 -I/opt/intel/compilers_and_libraries_2019.3.199/linux/mkl/include -march=x86-64 -mtune=generic -O2 -pipe -fno-plt $(LTO)
CXX11PICFLAGS = -fpic
CXX11STD = -std=gnu++11
CXX14 = g++
CXX14FLAGS =  -m64 -I/opt/intel/compilers_and_libraries_2019.3.199/linux/mkl/include -march=x86-64 -mtune=generic -O2 -pipe -fno-plt $(LTO)
CXX14PICFLAGS = -fpic
CXX14STD = -std=gnu++14
CXX17 = g++
CXX17FLAGS =  -m64 -I/opt/intel/compilers_and_libraries_2019.3.199/linux/mkl/include -march=x86-64 -mtune=generic -O2 -pipe -fno-plt $(LTO)
CXX17PICFLAGS = -fpic
CXX17STD = -std=gnu++17
CXX_VISIBILITY = -fvisibility=hidden
DYLIB_EXT = .so
DYLIB_LD = $(CC)
DYLIB_LDFLAGS = -shared -fopenmp# $(CFLAGS) $(CPICFLAGS)
DYLIB_LINK = $(DYLIB_LD) $(DYLIB_LDFLAGS) $(LDFLAGS)
ECHO = echo
ECHO_C = 
ECHO_N = -n
ECHO_T = 
F_VISIBILITY = -fvisibility=hidden
## FC is the compiler used for all Fortran as from R 3.6.0
FC = gfortran
FCFLAGS =  -m64 -I/opt/intel/compilers_and_libraries_2019.3.199/linux/mkl/include  $(LTO)
## additional libs needed when linking with $(FC), e.g. on some Oracle compilers
FCLIBS_XTRA = 
FFLAGS =  -m64 -I/opt/intel/compilers_and_libraries_2019.3.199/linux/mkl/include  $(LTO)
FLIBS =  -lgfortran -limf -lm -lquadmath
FPICFLAGS = -fpic
FOUNDATION_CPPFLAGS = 
FOUNDATION_LIBS = 
JAR = /usr/bin/jar
JAVA = /usr/bin/java
JAVAC = /usr/bin/javac
JAVAH = /usr/bin/javah
## JAVA_HOME might be used in the next three.  
## They are for packages 'JavaGD' and 'rJava'
JAVA_HOME = /usr/lib/jvm/java-8-openjdk/jre
JAVA_CPPFLAGS = -I$(JAVA_HOME)/../include -I$(JAVA_HOME)/../include/linux
JAVA_LIBS = -L$(JAVA_HOME)/lib/amd64/server -ljvm
JAVA_LD_LIBRARY_PATH = $(JAVA_HOME)/lib/amd64/server
LAPACK_LIBS = 
LDFLAGS = -Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now
## we only need this is if it is external, as otherwise link to R
LIBINTL= 
LIBM = -limf -lm
LIBR0 = -L"$(R_HOME)/lib$(R_ARCH)"
LIBR1 = -lR
LIBR = -L"$(R_HOME)/lib$(R_ARCH)" -lR
LIBS =  -lpcre2-8 -lpcre -llzma -lbz2 -lz -ltirpc -lrt -ldl -limf -lm -licuuc -licui18n
## needed by R CMD config
LIBnn = lib
LIBTOOL = $(SHELL) "$(R_HOME)/bin/libtool"
LTO = 
## needed to build applications linking to static libR
MAIN_LD = $(CC)
MAIN_LDFLAGS = -Wl,--export-dynamic -fopenmp
MAIN_LINK = $(MAIN_LD) $(MAIN_LDFLAGS) $(LDFLAGS)
MKINSTALLDIRS = "$(R_HOME)/bin/mkinstalldirs"
OBJC = gcc
OBJCFLAGS = -g -O2 -fobjc-exceptions $(LTO)
OBJC_LIBS = -lobjc 
OBJCXX = g++
R_ARCH = 
RANLIB = ranlib
SAFE_FFLAGS =  -m64 -I/opt/intel/compilers_and_libraries_2019.3.199/linux/mkl/include  -msse2 -mfpmath=sse
SED = /usr/bin/sed
SHELL = /bin/sh
SHLIB_CFLAGS = 
SHLIB_CXXFLAGS = 
SHLIB_CXXLD = $(CXX)
SHLIB_CXXLDFLAGS = -shared
SHLIB_CXX98LD = $(CXX98) $(CXX98STD)
SHLIB_CXX98LDFLAGS = -shared
SHLIB_CXX11LD = $(CXX11) $(CXX11STD)
SHLIB_CXX11LDFLAGS = -shared
SHLIB_CXX14LD = $(CXX14) $(CXX14STD)
SHLIB_CXX14LDFLAGS = -shared
SHLIB_CXX17LD = $(CXX17) $(CXX17STD)
SHLIB_CXX17LDFLAGS = -shared
SHLIB_EXT = .so
SHLIB_FFLAGS = 
SHLIB_LD = $(CC)
SHLIB_LDFLAGS = -shared# $(CFLAGS) $(CPICFLAGS)
SHLIB_LIBADD = 
## We want to ensure libR is picked up from $(R_HOME)/lib
## before e.g. /usr/local/lib if a version is already installed.
SHLIB_LINK = $(SHLIB_LD) $(SHLIB_LDFLAGS) $(LIBR0) $(LDFLAGS)
SHLIB_OPENMP_CFLAGS = -fopenmp
SHLIB_OPENMP_CXXFLAGS = -fopenmp
SHLIB_OPENMP_FFLAGS = -fopenmp
STRIP_STATIC_LIB = strip --strip-debug
STRIP_SHARED_LIB = strip --strip-unneeded
TCLTK_CPPFLAGS = -I/usr/include -I/usr/include 
TCLTK_LIBS = -L/usr/lib -ltcl8.6 -L/usr/lib -ltk8.6 -lX11 -lXss -lXext
YACC = bison -y

## Legacy settings:  no longer used by R as of 3.6.0
## Setting FC often sets F77 (on Solaris make even if set)
## so must follow FC in this file.
F77 = gfortran
FCPICFLAGS = -fpic
F77_VISIBILITY = -fvisibility=hidden
SHLIB_FCLD = $(FC)
SHLIB_FCLDFLAGS = -shared
SHLIB_OPENMP_FCFLAGS = -fopenmp


## for linking to libR.a
STATIC_LIBR = # -Wl,--whole-archive "$(R_HOME)/lib$(R_ARCH)/libR.a" -Wl,--no-whole-archive $(BLAS_LIBS) $(FLIBS)  $(LIBINTL) -lreadline  $(LIBS)

## These are recorded as macros for legacy use in packages
## set on AIX, formerly for old glibc (-D__NO_MATH_INLINES)
R_XTRA_CFLAGS = 
##  was formerly set on HP-UX
R_XTRA_CPPFLAGS =  -I"$(R_INCLUDE_DIR)" -DNDEBUG
## currently unset
R_XTRA_CXXFLAGS = 
## currently unset
R_XTRA_FFLAGS = 

## SHLIB_CFLAGS SHLIB_CXXFLAGS SHLIB_FFLAGS are apparently currently unused
## SHLIB_CXXFLAGS is undocumented, there is no SHLIB_FCFLAGS
ALL_CFLAGS =  $(PKG_CFLAGS) $(CPICFLAGS) $(SHLIB_CFLAGS) $(CFLAGS)
ALL_CPPFLAGS =  -I"$(R_INCLUDE_DIR)" -DNDEBUG $(PKG_CPPFLAGS) $(CLINK_CPPFLAGS) $(CPPFLAGS)
ALL_CXXFLAGS =  $(PKG_CXXFLAGS) $(CXXPICFLAGS) $(SHLIB_CXXFLAGS) $(CXXFLAGS)
ALL_OBJCFLAGS = $(PKG_OBJCFLAGS) $(CPICFLAGS) $(SHLIB_CFLAGS) $(OBJCFLAGS)
ALL_OBJCXXFLAGS = $(PKG_OBJCXXFLAGS) $(CXXPICFLAGS) $(SHLIB_CXXFLAGS) $(OBJCXXFLAGS)
ALL_FFLAGS =  $(PKG_FFLAGS) $(FPICFLAGS) $(SHLIB_FFLAGS) $(FFLAGS)
## can be overridden by R CMD SHLIB
P_FCFLAGS = $(PKG_FFLAGS)
ALL_FCFLAGS =  $(P_FCFLAGS) $(FPICFLAGS) $(SHLIB_FFLAGS) $(FCFLAGS)
## LIBR here as a couple of packages use this without SHLIB_LINK
ALL_LIBS = $(PKG_LIBS) $(SHLIB_LIBADD) $(LIBR)# $(LIBINTL)

.SUFFIXES:
.SUFFIXES: .c .cc .cpp .d .f .f90 .f95 .m .mm .M .o

.c.o:
    $(CC) $(ALL_CPPFLAGS) $(ALL_CFLAGS) -c $< -o $@
.c.d:
    @echo "making $@ from $<"
    @$(CC) -MM $(ALL_CPPFLAGS) $< > $@
.cc.o:
    $(CXX) $(ALL_CPPFLAGS) $(ALL_CXXFLAGS) -c $< -o $@
.cpp.o:
    $(CXX) $(ALL_CPPFLAGS) $(ALL_CXXFLAGS) -c $< -o $@
.cc.d:
    @echo "making $@ from $<"
    @$(CXX) -M $(ALL_CPPFLAGS) $< > $@
.cpp.d:
    @echo "making $@ from $<"
    @$(CXX) -M $(ALL_CPPFLAGS) $< > $@
.m.o:
    $(OBJC) $(ALL_CPPFLAGS) $(ALL_OBJCFLAGS) -c $< -o $@
.m.d:
    @echo "making $@ from $<"
    @gcc -MM $(ALL_CPPFLAGS) $< > $@
.mm.o:
    $(OBJCXX) $(ALL_CPPFLAGS) $(ALL_OBJCXXFLAGS) -c $< -o $@
.M.o:
    $(OBJCXX) $(ALL_CPPFLAGS) $(ALL_OBJCXXFLAGS) -c $< -o $@
.f.o:
    $(FC) $(ALL_FFLAGS) -c $< -o $@
## @FCFLAGS_f9x@ are flags needed to recognise the extensions
.f95.o:
    $(FC) $(ALL_FCFLAGS) -c  $< -o $@
.f90.o:
    $(FC) $(ALL_FCFLAGS) -c  $< -o $@

blazko commented on 2019-05-06 18:49 (UTC)

@alexenderp this is the code I'm running:

https://gist.github.com/b1azk0/db5f37da66b28ecbb1c0b40b68177702

I did this simulation on previous R version and it was just fine.

alexanderp commented on 2019-05-06 18:46 (UTC)

@mys_721tx, acepack installs fine on my side:

> install.packages("acepack")
trying URL 'https://cran.rstudio.com/src/contrib/acepack_1.4.1.tar.gz'
Content type 'application/x-gzip' length 34848 bytes (34 KB)
==================================================
downloaded 34 KB

* installing *source* package ‘acepack’ ...
** package ‘acepack’ successfully unpacked and MD5 sums checked
** using staged installation
** libs
gfortran  -fpic  -m64 -I/opt/intel/compilers_and_libraries_2019.3.199/linux/mkl/include   -c ace.f -o ace.o
gfortran  -fpic  -m64 -I/opt/intel/compilers_and_libraries_2019.3.199/linux/mkl/include   -c avas.f -o avas.o
gfortran  -fpic  -m64 -I/opt/intel/compilers_and_libraries_2019.3.199/linux/mkl/include   -c rlsmo.f -o rlsmo.o
gcc -shared -L/usr/lib64/R/lib -Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now -o acepack.so ace.o avas.o rlsmo.o -lgfortran -limf -lm -lquadmath -L/usr/lib64/R/lib -lR
installing to /home/user/R/x86_64-pc-linux-gnu-library/3.6/00LOCK-acepack/00new/acepack/libs
** R
** inst
** byte-compile and prepare package for lazy loading
** help
*** installing help indices
** building package indices
** testing if installed package can be loaded from temporary location
** checking absolute paths in shared objects and dynamic libraries
** testing if installed package can be loaded from final location
** testing if installed package keeps a record of temporary installation path
* DONE (acepack)

The downloaded source packages are in
    ‘/tmp/RtmpTd0Kjm/downloaded_packages’
> 

alexanderp commented on 2019-05-06 18:36 (UTC)

@blazko, I need something to test this claim. Can you please provide a reproducible example that made use of all cores before the update but does not now?

blazko commented on 2019-05-06 18:24 (UTC)

@alexanderp My .conf file is set up as before:

# Confgure the MKL multithreading
# for more details visit: http://software.intel.com/sites/products/documentatio>
#

# Uncomment if you want to set a constant number o threads.
export MKL_NUM_THREADS=32

# Uncomment and edit if you want to set the nr. of threads for every components.
# export MKL_DOMAIN_NUM_THREADS="MKL_ALL=4, MKL_BLAS=4"

# If TRUE MKL set automatically the optimal number of threads
#export MKL_DYNAMIC=TRUE

That does not help. I'm not sure what does this switch mean, but is there a way to make it use Intel back again?

alexanderp commented on 2019-05-06 18:05 (UTC) (edited on 2019-05-06 18:07 (UTC) by alexanderp)

@blazko The package recently switched from Intel threading to OpenMP. Can you please try setting the number of threads manually in /etc/intel-mkl-th.conf?

mys_721tx commented on 2019-05-05 16:30 (UTC) (edited on 2019-05-05 16:48 (UTC) by mys_721tx)

The -limf flag causes a problem when compiling acepack since /opt/intel/compilers_and_libraries_2019.3.199/linux/compiler/lib/intel64 is not in $FLIBS. The problem is resolved by adding -L/opt/intel/compilers_and_libraries_2019.3.199/linux/compiler/lib/intel64 to $FLIBS in /usr/lib/R/etc/Makeconf. Perhaps we should append it to wherever -limf appears.

> install.packages("acepack")
trying URL 'https://cloud.r-project.org/src/contrib/acepack_1.4.1.tar.gz'
Content type 'application/x-gzip' length 34848 bytes (34 KB)
==================================================
downloaded 34 KB

* installing *source* package ‘acepack’ ...
** package ‘acepack’ successfully unpacked and MD5 sums checked
** using staged installation
** libs
gfortran  -fpic  -m64 -I/opt/intel/compilers_and_libraries_2019.3.199/linux/mkl/include   -c ace.f -o ace.o
gfortran  -fpic  -m64 -I/opt/intel/compilers_and_libraries_2019.3.199/linux/mkl/include   -c avas.f -o avas.o
gfortran  -fpic  -m64 -I/opt/intel/compilers_and_libraries_2019.3.199/linux/mkl/include   -c rlsmo.f -o rlsmo.o
gcc -shared -L/usr/lib64/R/lib -Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now -o acepack.so ace.o avas.o rlsmo.o -lgfortran -limf -lm -lquadmath -L/usr/lib64/R/lib -lR
/usr/sbin/ld: cannot find -limf
collect2: error: ld returned 1 exit status
make: *** [/usr/share/R//make/shlib.mk:6: acepack.so] Error 1
ERROR: compilation failed for package ‘acepack’
* removing ‘/usr/lib/R/library/acepack’
* restoring previous ‘/usr/lib/R/library/acepack’

The downloaded source packages are in
    ‘/tmp/RtmpZqWncs/downloaded_packages’
Warning message:
In install.packages("acepack") :
  installation of package ‘acepack’ had non-zero exit status

blazko commented on 2019-05-04 06:58 (UTC) (edited on 2019-05-04 07:05 (UTC) by blazko)

Thanks it worked.

The new version (with newest intel-mkl) does not recognize all 32 cores on my xeon. When running simr() it now uses only 16, and with previous version it used all of them at 100%.

Is this something I can restore?

As a side note: other multicore applications still can run at 100% resources. It's something that changed for R only

alexanderp commented on 2019-05-03 12:48 (UTC) (edited on 2019-05-03 12:48 (UTC) by alexanderp)

https://wiki.archlinux.org/index.php/Pacman#%22Failed_to_commit_transaction_(conflicting_files)%22_error

blazko commented on 2019-05-03 12:08 (UTC) (edited on 2019-05-03 12:45 (UTC) by blazko)

@alexanderp thing is, there are a couple of those (survival.R) is just one of them. Is there any --overwrite all option? :)

error: failed to commit transaction (conflicting files)
r-mkl: /usr/lib/R/library/rpart/help/figures/rpart.png exists in filesystem
r-mkl: /usr/lib/R/library/survival/doc/survival.R exists in filesystem
r-mkl: /usr/lib/R/library/survival/doc/survival.Rnw exists in filesystem
r-mkl: /usr/lib/R/library/survival/doc/survival.pdf exists in filesystem
r-mkl: /usr/lib/R/library/survival/help/figures/logo.png exists in filesystem
Errors occurred, no packages were upgraded.
==> WARNING: Your packages are saved in /tmp/yaourt-tmp-bajzel

alexanderp commented on 2019-05-03 11:36 (UTC)

@blazko Try adding --overwrite usr/lib/R/library/survival/doc/survival.R to your pacman command. My own installations upgraded fine by the way.

blazko commented on 2019-05-03 11:00 (UTC)

I'm getting r-mkl: /usr/lib/R/library/survival/doc/survival.R already exists in filesystem with a couple others when trying to upgrade from last 3.5 version. Should I remove old install completely before trying to upgrade?

alyst commented on 2019-04-23 12:35 (UTC)

@alexanderp My laptop's march is skylake. I can try some R benchmarks/tests (which ones do you have in mind?) with the current r-mkl CFLAGS (-O3 -m64 -march=native -I...) vs the proposed ones (${CFLAGS} -m64 -I..., where $CFLAGS is from makepkg.conf with "-march=x86_64" set by default).

The second part (intel compiler dependency) should not affect it, though. There was a problem before was intel-mkl implicitly depending on intel-compiler-based, but I've just fixed it.

There's another potential issue that R-MKL uses Intel OpenMP with GCC compiler instead of GCC's own implementation. As some of the R packages may explicitly use -fopenmp, this may cause some issues either at compile or run time. Here's a fix for that:

@@ -113,16 +118,16 @@ build() {
     export FFLAGS="${_intel_cc_opt}"
     export FCFLAGS="${_intel_cc_opt}"
   else
     _gcc_opt=" -O3 -m64 -march=native -I${MKLROOT}/include"
     # export LDFLAGS=" -fopenmp"

     # Dynamic Linking
     _mkllibs=" -L${MKLROOT}/lib/${_intel_arch} \
       -Wl,--no-as-needed \
       -l${_gfortran_lib} \
-      -lmkl_intel_thread \
+      -lmkl_gnu_thread \
       -lmkl_core \
-      -liomp5 \
+      -fopenmp \
       -lpthread \
       -lm \
       -ldl"

alexanderp commented on 2019-04-22 19:54 (UTC)

@alyst Thanks for the diff. You make an interesting point, especially about respecting the users' makepkg.conf.

From my own experience, linking R with the MKL is very sensitive with respect to compiler flags and requires some fine-tuning to make sure that base R and some popular libraries compile correctly and that tests do not fail or deviate from the expected value. Carrying over any custom settings set in makepkg.conf could introduce errors.

What is the output of gcc -c -Q -march=native --help=target | grep -i 'march=\|mtune='? Could you provide compilation, test and benchmark logs for comparing the current PKGBUILD with the proposed changes?

I think the way forward would be to introduce a local variable to switch between native and makepkg.conf (generic) flags. I'd also be interested in hearing others' opinion on this.

alyst commented on 2019-04-22 16:28 (UTC)

Here's the proposed changes. I have also made the dependencies dynamically depend on _CC var (so that GCC-compiled package doesn't depend on intel compilers) + removed !makeflags (it only affected MAKEFLAGS anyway):

diff --git a/PKGBUILD b/PKGBUILD
index 8a315e6..77fc4f7 100644
--- a/PKGBUILD
+++ b/PKGBUILD
@@ -13,12 +13,8 @@ url='http://www.r-project.org/'
 provides=("r=${pkgver}")
 conflicts=('r' 'microsoft-r-open')
 depends=('intel-mkl'
-        'intel-compiler-base'
-        'intel-fortran-compiler'
         'bzip2'
         'desktop-file-utils'
-        'gcc-libs'
-        'gcc-fortran'
         'icu'
         'libjpeg'
         'libpng'
@@ -44,7 +40,7 @@ backup=('etc/R/Makeconf'
         'etc/R/ldpaths'
         'etc/R/repositories'
         'etc/R/javaconf')
-options=('!makeflags' '!emptydirs')
+options=('!emptydirs')
 install=r-mkl.install

 source=("http://cran.r-project.org/src/base/R-${pkgver%%.*}/R-${pkgver}.tar.gz"
@@ -65,6 +61,15 @@ sha512sums=('077cbd4bc9f19a3a2485afbd4d8e08e0754ddcb9a10164cbc8478f239d5ed0ffaf6
 # Comment the following line to build the package with GCC
 # _CC="icc"

+# update dependencies w.r.t the compiler used
+if [[ $_CC = "icc" ]]; then
+  depends+=('intel-compiler-base'
+            'intel-fortran-compiler')
+else
+  depends+=('gcc-libs'
+            'gcc-fortran')
+fi
+
 prepare() {
   cd R-${pkgver}
   # set texmf dir correctly in makefile
@@ -113,7 +118,7 @@ build() {
     export FFLAGS="${_intel_cc_opt}"
     export FCFLAGS="${_intel_cc_opt}"
   else
-    _gcc_opt=" -O3 -m64 -march=native -I${MKLROOT}/include"
+    _gcc_opt="-m64 -I${MKLROOT}/include"
     # export LDFLAGS=" -fopenmp"

     # Dynamic Linking
@@ -133,10 +138,10 @@ build() {
     export LD="ld"
     export F77="gfortran"
     export FC="gfortran"
-    export CFLAGS="${_gcc_opt}"
-    export CXXFLAGS="${_gcc_opt}"
-    export FFLAGS="${_gcc_opt}"
-    export FCFLAGS="${_gcc_opt}"
+    export CFLAGS="$CFLAGS ${_gcc_opt}"
+    export CXXFLAGS="$CXXFLAGS ${_gcc_opt}"
+    export FFLAGS="$FFLAGS ${_gcc_opt}"
+    export FCFLAGS="$FCFLAGS ${_gcc_opt}"
   fi

   ./configure  --prefix=/usr \

alyst commented on 2019-04-22 15:03 (UTC)

Currently, r-mkl overrides the -march GCC switch from "makepkg.conf" and sets it to "native". While I understand the intention, this creates problems for some scenarios.

E.g. I'm trying to make a docker image for a slightly different architecture than my local machine. So I have the proper "-march" switch in "makepkg.conf", but it would be ignored by r-mkl PKGBUILD. One possibility would be to fix the PKGBUILD from within Dockerfile, but that doesn't play well with using AUR helpers like yay or pikaur to automatically manage dependencies.

Would it be possible to implement either: 1) respect XXXFLAGS set by makepkg.conf and only minimally modify them (just append "-m64 -I...") 2) change PKGBUILD to -march=$CC_ARCH, where CC_ARCH is some envvar that defaults to "native"?

pat-s commented on 2018-08-12 17:33 (UTC)

@nessuno Well, the most recent icu is v62.1 so maybe that the reason why the fix does not work for you? Other libraries (including r-mkl) using icu need to be reinstalled after an icu update to work with the most recent version.

Anyways, r-mkl does not have any responsibility here so the discussion is actually off-topic.

nessuno commented on 2018-08-12 13:22 (UTC)

The package glibc-fix-r-and-electron-git doesn't solve the problem for me. Anyway the solution I proposed before works. Moreover, I also uploaded a new AUR package "icu61" to solve the problem of the libicuuc.so.61 libraries request. If anyone have a better and more proper solution for these problems, please let me know.

pat-s commented on 2018-08-12 08:51 (UTC)

Install this hotfix version of glibc-2.28 and you can use R again without problems and also upgrade all other libraries again: https://bugs.archlinux.org/task/59550#comment171883

nessuno commented on 2018-08-12 07:45 (UTC)

Thanks to an advice on the rstudio-desktop-bin package page I solved the aforementioned problem through

devtools::install_github('r-lib/later')

But now I've also another problem, since the libicuuc.so.61 is required. I saw there are other older icu versions on AUR, but the 61 is lacking. Is there anyone that is able to help me.

Thank you very much as always

nessuno commented on 2018-08-09 14:33 (UTC) (edited on 2018-08-09 14:34 (UTC) by nessuno)

Problem solved downgrading glibc from 2.28 to 2.27

Thanks so much for the help

alexanderp commented on 2018-08-08 06:57 (UTC)

@nessuno, probably something related to glibc.

See https://github.com/rstudio/shiny/issues/2150 and https://bugs.archlinux.org/task/59550

nessuno commented on 2018-08-07 20:40 (UTC)

After the last update of the package I have this errore when I try to install sparklyr

terminate called after throwing an instance of 'std::runtime_error'
  what():  Mutex creation failed
/usr/lib64/R/bin/INSTALL: line 34: 10596 Done                    echo 'tools:::.install_packages()'
     10597 Aborted                 (core dumped) | R_DEFAULT_PACKAGES= LC_COLLATE=C "${R_HOME}/bin/R" $myArgs --slave --args ${args}

Someone is able to help me in understanding what it means and how to solve it?

Thanks so much!

mys_721tx commented on 2018-07-03 01:09 (UTC)

The new types defined in GCC 7 (_Float32, _Float32x, etc) seems to caused the problem.

mys_721tx commented on 2018-06-02 00:47 (UTC)

==> ERROR: provides contains invalid characters: '=,'

alexanderp commented on 2018-04-26 18:51 (UTC)

Updated to 3.5.0.

WARNING: Compilation with icc/ifort is broken.

alexanderp commented on 2018-03-30 13:20 (UTC) (edited on 2018-03-30 13:21 (UTC) by alexanderp)

@pat-s In my experience, no, I've never had freezes during normal usage. I've been using R with the Intel MKL on all my computers for several years.

The only drawback I found was that some packages are not compatible with icc/icpc, therefore I sometimes need to fallback to gcc/gfortran in ~/.R/Makevars (e.g. for the forecast package)

Glad to hear it's working properly on your side now.

pat-s commented on 2018-03-29 19:35 (UTC) (edited on 2018-03-29 20:30 (UTC) by pat-s)

Usage related: I encountered several "freezes" during usage that only occurred with the "intel-mkl" library (not with openblas or default blas). No error is thrown, the process is just stuck at some point and there is no way to track down the problem. I'll try it again with the latest version, maybe something changed. Just wondering if anyone else faced similar problems in the past?

EDIT: Installation worked and the errors mentioned have vanished. Thanks!

mys_721tx commented on 2018-03-29 02:55 (UTC)

@alexanderp : r-mkl-3.4.4-3 compiled with icc without any problem!

mys_721tx commented on 2018-03-29 02:01 (UTC)

@alexanderp : I remembered it wrong. It was hung on the check stage.

checking package 'Matrix'
* using log directory ‘/home/mys_721tx/r-mkl/src/R-3.4.4/tests/Matrix.Rcheck’
* using R version 3.4.4 (2018-03-15)
* using platform: x86_64-pc-linux-gnu (64-bit)
* using session charset: UTF-8
* checking for file ‘Matrix/DESCRIPTION’ ... OK
* this is package ‘Matrix’ version ‘1.2-12’
* package encoding: UTF-8
* checking package namespace information ... OK
* checking package dependencies ... NOTE
Package suggested but not available for checking: ‘expm’

Packages which this enhances but not available for checking:
  ‘MatrixModels’ ‘graph’ ‘SparseM’ ‘sfsmisc’
* 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 ‘build’ 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
Packages unavailable to check Rd xrefs: ‘SparseM’, ‘spdep’, ‘expm’, ‘graph’, ‘igraph’, ‘sfsmisc’, ‘MatrixModels’
* 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 shell scripts ... 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 installed files from ‘inst/doc’ ... OK
* checking files in ‘vignettes’ ... OK
* checking examples ... OK
* checking for unstated dependencies in ‘tests’ ... OK
* checking tests ...
  Running ‘Class+Meth.R’
  Running ‘Simple.R’

alexanderp commented on 2018-03-29 01:45 (UTC)

@mys_721tx compilation with icc should be fixed now.

@nessuno I'll look into it.

nessuno commented on 2018-03-28 13:26 (UTC) (edited on 2018-03-28 13:27 (UTC) by nessuno)

There's still an error (I don't know if significant)

Running the tests in ‘tests/sigma-fixed-etc.R’ failed.
Last 13 lines of output:
  > ##------------------------------------------------------ REML ---
  > method <- "REML"
  > cat("\nFixed sigma= ",sigma,"  estimation method ", method,"\n")

  Fixed sigma=  1   estimation method  REML 
  > t7.fix.REML.lme <- lme( current ~voltage + I(voltage^2), data = Wafer,
  +                        random = list(Wafer = pdDiag(~voltage + I(voltage^2)),
  +                                      Site  = pdDiag(~voltage + I(voltage^2)) ),
  +                        control = lmeControl(sigma = 1),
  +                        method = method)
  Error in lme.formula(current ~ voltage + I(voltage^2), data = Wafer, random = list(Wafer = pdDiag(~voltage +  : 
    nlminb problem, convergence error code = 1
    message = false convergence (8)
  Calls: lme -> lme.formula
  Execution halted

but now it works for me, thanks!

alexanderp commented on 2018-03-28 13:01 (UTC) (edited on 2018-03-28 13:06 (UTC) by alexanderp)

@mys_721tx, it must be due to a missing dependency from Intel Parallel Studio. I'll have another look. Just to clarify, you're getting the hangup during checking, not building, right?

mys_721tx commented on 2018-03-28 00:33 (UTC)

So I enabled icc and was hang on "Running ‘Simple.R’" when building Matrix. I have openmp and ice installed. It seems to be the same problem as the one jbmorgado had. What kind of log should I provide?

alexanderp commented on 2018-03-27 22:51 (UTC) (edited on 2018-03-29 01:43 (UTC) by alexanderp)

Thanks for the reports. The Matrix hangup issue when using gcc is fixed as of 3.4.4-2.

Version 3.4.4-3 fixes compilation with icc as well.

Please note that there's a bug in intel-tbb_psxe. Specifically, /etc/ld.so.conf.d/intel-tbb.conf should contain /opt/intel/composerxe/linux/tbb/lib/intel64/gcc4.7

japhir commented on 2018-03-22 12:00 (UTC)

I have the same errors as nessuno. I htop to see what's causing the hang-up after waiting for a reasonable time, and then F9 sigterm the offending process. They are the same as he listed, plus a checking of vignette output thing that keeps hanging. It now succesfully builds, but somehow when I run a function from a package that falls back to fortran code, it causes a segfault :(.

nessuno commented on 2018-03-17 20:33 (UTC) (edited on 2018-03-17 20:35 (UTC) by nessuno)

I hope to be helpful, even though I'm not a so expert user.

I have the same error of @pat-s. I think that the problem is at row 1031 of Simple.R. It uses checkMatrix that requires to convert the sparse matrix in a "simple" matrix, but for the matrix named "S.na" it gives me

Error in as(S.na, "martix") : 
  no method or default for coercing “dgCMatrix” to “martix”

Enter a frame number, or 0 to exit   

1: as(S.na, "martix")

Selection: as(S.na, "matrix")
Enter an item from the menu, or 0 to exit

But it gives me errors also in other three files

  • Comparisons.Rnw
  • sparseModels.Rnw
  • mgcv-parallel.R

but I didn't understand precisely where by the moment.

Said that, if I skip them, by killing the R process each time (I don't how to do it in a cleaner way), it compiles and everithing seems to work then. But I don't know if it's ok or not.

Hoping it can help, let me know if I can do something else.

pat-s commented on 2018-03-17 11:39 (UTC)

Here's a gist: https://gist.github.com/pat-s/09029269cf02a8e5642a0f81dcf77cd6

Idk which additional information you would need. Just tell me :)

As said, this happens with the standard PKGBUILD and gcc v7.3

alexanderp commented on 2018-03-16 20:11 (UTC)

Updated to 3.4.4

@jbmorgado and @pat-s: I cannot reproduce the Simple.R issue on my machine when compiling with gcc. Only when compiling with icc

Can you send a log file with more information?

pat-s commented on 2018-03-11 22:46 (UTC)

I was able to get it building by commenting out the "check" section of the PKGBUILD:

check() { cd R-${pkgver} make check-recommended }

pat-s commented on 2018-03-11 22:40 (UTC)

@alexanderp I am also stuck at the same issue as @jbmorgado. Its stuck running the test script of the "Matrix" package called "Simple.R". Building with gcc. Its the default anyways in the current PKGBUILD.

alexanderp commented on 2018-02-17 10:47 (UTC)

@jbmorgado, make sure you're compiling with gcc and not with icc, i.e. the _CC="icc" line should be commented out. Unfortunately, R seems to be incompatible with recent releases of the Intel compilers.

jbmorgado commented on 2018-02-10 11:29 (UTC) (edited on 2018-02-10 11:29 (UTC) by jbmorgado)

Can't compile this.

Gets stuck for hours during compilation at: "Running ‘Simple.R’"

mys_721tx commented on 2017-11-16 17:29 (UTC)

icc 18.0.1 is out, it should fix the gcc 7.0 compatibility issue https://software.intel.com/en-us/forums/intel-c-compiler/topic/742701

alexanderp commented on 2017-04-24 18:40 (UTC)

Yes, compilation was fixed with my last update on 2017-03-06.

gergi commented on 2017-04-24 07:29 (UTC)

Compiles again smoothly. zlib issue got fixed in https://stat.ethz.ch/pipermail/r-help//2017-January/444162.html

alexanderp commented on 2017-02-16 17:07 (UTC)

That's a general problem with zlib. Even vanilla R from the repositories doesn't compile.

adalardo commented on 2017-02-14 11:43 (UTC)

Same here checking if zlib version >= 1.2.5... no checking whether zlib support suffices... configure: error: zlib library and headers are required The zlib version installed is 1:1.2.11. I believe the problem is "1:" before official version name.

gergi commented on 2017-02-07 15:11 (UTC)

Build fails on checking if zlib version >= 1.2.5... no checking whether zlib support suffices... configure: error: zlib library and headers are required

herraiz commented on 2016-11-20 22:42 (UTC)

Excellent, thanks @alexanderp!

alexanderp commented on 2016-11-20 21:01 (UTC)

Herraiz, thank you for the insight in compiling quantreg and igraph. I've implemented your suggestion in the ./configure line instead of Makeconf. It seems that -lifcore and -lifport needed to be included before and after -lm.

herraiz commented on 2016-11-20 17:41 (UTC)

Here is the same patch against the current master: From 79b350c7f58018b28374201fc3d644b3bd2696ce Mon Sep 17 00:00:00 2001 From: "Israel Herraiz <isra@herraiz.org>" Date: Sun, 20 Nov 2016 18:39:02 +0100 Subject: [PATCH] Patch for Makeconf.in --- PKGBUILD | 14 ++++++++++---- makeconf.in.patch | 11 +++++++++++ 2 files changed, 21 insertions(+), 4 deletions(-) create mode 100644 makeconf.in.patch diff --git a/PKGBUILD b/PKGBUILD index 348fa61..3a19729 100644 --- a/PKGBUILD +++ b/PKGBUILD @@ -48,16 +48,20 @@ install=r-mkl.install source=("http://cran.r-project.org/src/base/R-${pkgver%%.*}/R-${pkgver}.tar.gz" 'r.desktop' 'r.png' - 'R.conf') - + 'R.conf' + 'makeconf.in.patch' + ) md5sums=('2437014ef40641cdc9673e89c040b7a8' '44ca875140b148543148b7749c7d6f5e' '8e0c51650b8a63f110fa7b09e699e9c4' - '1dfa62c812aed9642f6e4ac34999b9fe') + '1dfa62c812aed9642f6e4ac34999b9fe' + 'd7cf18f67e7e76cc81fed1a2a3e654de') sha512sums=('06a98687c0b180cb0bfd57440ea26088212d9f48948d503136475bf54b42d72cfec5bea7e333c0cedd60733bd614dd0f8c2eced7e24478b6c89f48e8d0c43482' '1a90aed5411d72dd3e7708db0cb92c518e656e1a510ece02ad934131e05b8e683b4a36da8d37198263dc19fb2f3f19656c19c01f9b67974f0d7755974076d0b7' '1491b01d3d14b86d26c383e00e2305858a52ddd498158c9f7f6b33026ee01f246408b1676cffea73f7783c8c4cf546285705c43c0286adbd75ad77706918b5fe' - 'aae388c5b6c02d9fb857914032b0cd7d68a9f21e30c39ba11f5a29aaf1d742545482054b57ce18872eabb6605bbb359b2fc1e9be5ce6881443fdbdf6b67fab3b') + 'aae388c5b6c02d9fb857914032b0cd7d68a9f21e30c39ba11f5a29aaf1d742545482054b57ce18872eabb6605bbb359b2fc1e9be5ce6881443fdbdf6b67fab3b' + 'e04288ec8bed02dc4f5e4441285dba499390c78e5a4df8a82718b2905eed3c3a75828bebe4f5fddd1fab5831f0fc764df062f8f8bd971cb2e90352ea240218ac') + # Build with GCC/GFortran or the Intel Compiler Suite _CC="icc" # comment to build with GCC @@ -70,6 +74,8 @@ prepare() { sed -i 's|test ${makeinfo_version_min} -lt 7|test ${makeinfo_version_min} -lt 0|' configure # Fix the config script to look in Makeconf for LDFLAGS sed -i '/LIBS=`eval $query VAR=LIBS`/a\LDFLAGS=`eval $query VAR=LDFLAGS`' src/scripts/config + + patch -p2 < ../makeconf.in.patch } build() { diff --git a/makeconf.in.patch b/makeconf.in.patch new file mode 100644 index 0000000..98d09b5 --- /dev/null +++ b/makeconf.in.patch @@ -0,0 +1,11 @@ +--- src/R-3.3.2/etc/Makeconf.in 2016-03-17 00:04:44.000000000 +0100 ++++ src/R-3.3.2/etc/Makeconf.in.new 2016-11-20 18:35:47.681107000 +0100 +@@ -10,7 +10,7 @@ + include $(R_SHARE_DIR)/make/vars.mk + + AR = @AR@ +-BLAS_LIBS = @BLAS_LIBS@ ++BLAS_LIBS = @BLAS_LIBS@ -lifcore -lifport + C_VISIBILITY = @C_VISIBILITY@ + CC = @CC@ + CFLAGS = @CFLAGS@ $(LTO) -- 2.10.2

herraiz commented on 2016-11-20 17:25 (UTC)

Could you add a patch for Makeconf.in? The patch is the following one: 14c14 < BLAS_LIBS = @BLAS_LIBS@ --- > BLAS_LIBS = @BLAS_LIBS@ -lifcore -lifport It prevents problems when compiling some R packages. With that change, I was able to install quantreg and igraph. See comment from AnRe005 2016-08-07 09:22

hike commented on 2016-11-08 04:26 (UTC)

For people struggling with this. If you are a student, you can download and install intel dependencies (intel-compiler-base, intel-fortran-compiler, intel-mkl) for free from here https://software.intel.com/en-us/qualify-for-free-software/student When you install the latest version, compilers are installed in a different folder, so you have to change the path in line 89 in PKGBUILD from /opt/intel/composerxe/linux/bin/compilervars.sh to /opt/intel/compilers_and_libraries/linux/bin/compilervars.sh You will have to source compilervars.sh in bash before running R, otherwise, it won't run (just put it in .bashrc, but know that other compilations will be affected by this). In addition, intel installer might complain that your gcc and other libs are outdated, but if you have everything installed from core and multilib, you should be fine (I didn't get the -git packages).

leonardof commented on 2016-10-03 21:17 (UTC)

Follow-up: it turns out the community license is not meant for compiling software, after all... Too bad I don't know any binary package of r-mkl for Arch Linux.

leonardof commented on 2016-09-17 20:42 (UTC)

Thank you, alexanderp!

alexanderp commented on 2016-09-17 10:16 (UTC)

leonardof, I suggest you follow up your problem with the intel forums. You've probably got the wrong license and this page is not the place for these kinds of issues. Once you've got the intel compilers working, try using r-mkl again.

leonardof commented on 2016-09-17 03:51 (UTC) (edited on 2016-09-25 16:49 (UTC) by leonardof)

I can't compile r-mkl despite having got the community license and having put the LIC file at /opt/intel/licenses/. Reading r-mkl/src/R-3.3.1/config.log (see excerpt below), I gather that somehow my license isn't valid... How can it be? configure:5750: checking for gcc configure:5777: result: icc configure:6006: checking for C compiler version configure:6015: icc --version >&5 Error: A license for (Comp-CL) could not be found. License file(s) used were (in this order): 1. Trusted Storage ** 2. /opt/intel/composerxe/linux/licenses ** 3. /opt/intel/licenses/NCOM____XXXX-XXXXXXXX_1.lic ** 4. /opt/intel/licenses/NCOM____XXXX-XXXXXXXX_2.lic ** 5. /home/leonardof/intel/licenses ** 6. /opt/intel/compilers_and_libraries_2017.0.098/linux/bin/intel64/../../Licenses ** 7. /home/leonardof/Licenses ... rest of stderr output deleted ... configure:6026: $? = 1 configure:6015: icc -v >&5 Error: A license for (Comp-CL) could not be found. License file(s) used were (in this order): 1. Trusted Storage ** 2. /opt/intel/composerxe/linux/licenses ** 3. /opt/intel/licenses/NCOM____XXXX-XXXXXXXX_1.lic ** 4. /opt/intel/licenses/NCOM____XXXX-XXXXXXXX_2.lic ** 5. /home/leonardof/intel/licenses ** 6. /opt/intel/compilers_and_libraries_2017.0.098/linux/bin/intel64/../../Licenses ** 7. /home/leonardof/Licenses ... rest of stderr output deleted ... configure:6026: $? = 1 configure:6015: icc -V >&5 Error: A license for (Comp-CL) could not be found. License file(s) used were (in this order): 1. Trusted Storage ** 2. /opt/intel/composerxe/linux/licenses ** 3. /opt/intel/licenses/NCOM____XXXX-XXXXXXXX_1.lic ** 4. /opt/intel/licenses/NCOM____XXXX-XXXXXXXX_2.lic ** 5. /home/leonardof/intel/licenses ** 6. /opt/intel/compilers_and_libraries_2017.0.098/linux/bin/intel64/../../Licenses ** 7. /home/leonardof/Licenses ... rest of stderr output deleted ... configure:6026: $? = 1 configure:6015: icc -qversion >&5 Error: A license for (Comp-CL) could not be found. License file(s) used were (in this order): 1. Trusted Storage ** 2. /opt/intel/composerxe/linux/licenses ** 3. /opt/intel/licenses/NCOM____XXXX-XXXXXXXX_1.lic ** 4. /opt/intel/licenses/NCOM____XXXX-XXXXXXXX_2.lic ** 5. /home/leonardof/intel/licenses ** 6. /opt/intel/compilers_and_libraries_2017.0.098/linux/bin/intel64/../../Licenses ** 7. /home/leonardof/Licenses ... rest of stderr output deleted ... configure:6026: $? = 1 configure:6046: checking whether the C compiler works configure:6068: icc -O3 -qno-opt-matmul -xHost -m64 -parallel -mkl=parallel -qopenmp -ipo -fp-model precise -fp-model source -qopt-mem-layout-trans=2 -diag-disable=188,308 -I/opt/intel/composerxe/linux/mkl/include -D_FORTIFY_SOURCE=2 -Wl,-O1,--sort-common,--as-needed,-z,relro conftest.c >&5 Error: A license for (Comp-CL) could not be found. License file(s) used were (in this order): 1. Trusted Storage ** 2. /opt/intel/composerxe/linux/licenses ** 3. /opt/intel/licenses/NCOM____XXXX-XXXXXXXX_1.lic ** 4. /opt/intel/licenses/NCOM____XXXX-XXXXXXXX_2.lic ** 5. /home/leonardof/intel/licenses ** 6. /opt/intel/compilers_and_libraries_2017.0.098/linux/bin/intel64/../../Licenses ** 7. /home/leonardof/Licenses ** 8. /Users/Shared/Library/Application Support/Intel/Licenses ** 9. /opt/intel/compilers_and_libraries_2017.0.098/linux/bin/intel64/*.lic Please refer https://software.intel.com/en-us/faq/licensing#invalid-license-error for more information.. icc: error #10052: could not checkout FLEXlm license The second LIC file was an attempted workaround, using the MAC address of the wifi instead of the ethernet.

alexanderp commented on 2016-09-09 07:14 (UTC)

You should get a license to use Intel MKL. See https://wiki.archlinux.org/index.php/Intel_C%2B%2B

GeorgeChao commented on 2016-09-09 06:47 (UTC)

I found my config.log. As follows, --- configure:5690: result: /usr/bin/pkg-config configure:5750: checking for gcc configure:5777: result: icc -std=c99 configure:6006: checking for C compiler version configure:6015: icc -std=c99 --version >&5 Error: A license for Comp-CL could not be obtained (-1,359,2). Is your license file in the right location and readable? The location of your license file should be specified via the $INTEL_LICENSE_FILE environment variable. License file(s) used were (in this order): 1. Trusted Storage ** 2. /opt/intel/composerxe/linux/licenses ... rest of stderr output deleted ... configure:6026: $? = 1 configure:6015: icc -std=c99 -v >&5 Error: A license for Comp-CL could not be obtained (-1,359,2). Is your license file in the right location and readable? The location of your license file should be specified via the $INTEL_LICENSE_FILE environment variable. License file(s) used were (in this order): 1. Trusted Storage ** 2. /opt/intel/composerxe/linux/licenses

GeorgeChao commented on 2016-09-09 06:47 (UTC)

I found my config.log. As follows, --- configure:5690: result: /usr/bin/pkg-config configure:5750: checking for gcc configure:5777: result: icc -std=c99 configure:6006: checking for C compiler version configure:6015: icc -std=c99 --version >&5 Error: A license for Comp-CL could not be obtained (-1,359,2). Is your license file in the right location and readable? The location of your license file should be specified via the $INTEL_LICENSE_FILE environment variable. License file(s) used were (in this order): 1. Trusted Storage ** 2. /opt/intel/composerxe/linux/licenses ... rest of stderr output deleted ... configure:6026: $? = 1 configure:6015: icc -std=c99 -v >&5 Error: A license for Comp-CL could not be obtained (-1,359,2). Is your license file in the right location and readable? The location of your license file should be specified via the $INTEL_LICENSE_FILE environment variable. License file(s) used were (in this order): 1. Trusted Storage ** 2. /opt/intel/composerxe/linux/licenses

GeorgeChao commented on 2016-09-09 06:31 (UTC)

my C compiler got some error. --- gcc -version Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/6.2.1/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/ --enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared --enable-threads=posix --enable-libmpx --with-system-zlib --with-isl --enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object --enable-linker-build-id --enable-lto --enable-plugin --enable-install-libiberty --with-linker-hash-style=gnu --enable-gnu-indirect-function --disable-multilib --disable-werror --enable-checking=release Thread model: posix gcc version 6.2.1 20160830 (GCC) Error output --- 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 `/home/gg/softwares/r-mkl_R-3.3.1/src/R-3.3.1': configure: error: C compiler cannot create executables See `config.log' for more details ==> ERROR: A failure occurred in build(). Aborting...

AnRe005 commented on 2016-08-07 09:22 (UTC)

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 (UTC)

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

AnRe005 commented on 2016-07-05 07:09 (UTC)

The md5sum and md512sum for r.png have changed. New md5sum: 8e0c51650b8a63f110fa7b09e699e9c4 New md512sum: 1491b01d3d14b86d26c383e00e2305858a52ddd498158c9f7f6b33026ee01f246408b1676cffea73f7783c8c4cf546285705c43c0286adbd75ad77706918b5fe

lennartv commented on 2016-06-25 19:49 (UTC) (edited on 2016-06-25 20:24 (UTC) by lennartv)

[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 (UTC)

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 (UTC)

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 (UTC)

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 (UTC)

Thank you Alexanderp!

AnRe005 commented on 2016-06-17 11:28 (UTC)

Thanks for the fix. :-)

alexanderp commented on 2016-06-17 09:28 (UTC) (edited on 2016-06-17 09:28 (UTC) by alexanderp)

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

greenisagoodcolo commented on 2016-06-17 06:49 (UTC) (edited on 2016-06-17 06:58 (UTC) by greenisagoodcolo)

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 (UTC)

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 (UTC)

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 (UTC)

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 (UTC)

Thanks for your reply. Then I'll use the GCC compilers until this is fixed.

alexanderp commented on 2016-06-15 17:18 (UTC)

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 (UTC)

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 (UTC)

No problem. Please keep us updated.

nacnudus commented on 2016-06-03 11:14 (UTC)

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 (UTC)

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 (UTC)

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 (UTC)

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 (UTC)

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 (UTC)

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 (UTC)

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 (UTC)

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

commented on 2016-05-16 21:17 (UTC)

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 (UTC) (edited on 2016-05-04 12:55 (UTC) by alexanderp)

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 (UTC)

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 (UTC)

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 (UTC)

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

alexanderp commented on 2016-01-20 20:59 (UTC) (edited on 2016-01-20 21:00 (UTC) by alexanderp)

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 (UTC) (edited on 2015-12-20 15:32 (UTC) by alexanderp)

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 (UTC)

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 (UTC)

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

halfhorn commented on 2015-06-27 17:39 (UTC)

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

leonardof commented on 2015-06-04 00:06 (UTC)

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 (UTC)

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 (UTC)

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 (UTC)

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

setbl commented on 2014-09-13 14:20 (UTC)

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 (UTC)

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.

gabx commented on 2014-09-02 07:39 (UTC)

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 (UTC)

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 (UTC)

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.

setbl commented on 2014-08-24 13:40 (UTC)

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 (UTC)

Sorry, I forgot to mention I was using icc.

tklee commented on 2014-07-15 02:21 (UTC)

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 (UTC)

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 (UTC)

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.

jdarch commented on 2014-01-03 14:32 (UTC)

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

jdarch commented on 2013-12-24 10:05 (UTC)

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 .

zeltak commented on 2013-12-22 12:48 (UTC)

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 (UTC)

jdarch: Ok, it is done!

jdarch commented on 2013-10-24 12:15 (UTC)

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.

aberkoke commented on 2013-10-24 10:50 (UTC)

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 (UTC)

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-04 07:23 (UTC)

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 (UTC)

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 (UTC)

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 (UTC)

Updated to 3.0.1

matmo commented on 2012-10-17 09:02 (UTC)

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

commented on 2011-07-10 09:44 (UTC)

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!

commented on 2011-06-26 00:40 (UTC)

Updated to 2.13.0

giniu commented on 2011-02-14 09:41 (UTC)

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-11-10 21:09 (UTC)

updated to MKL 10.3

giniu commented on 2010-07-30 19:19 (UTC)

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 (UTC)

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.