Arch Linux User Repository

@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.

@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.

@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

@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.

@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

@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

@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

@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...

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

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

@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.

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

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.

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

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

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?

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

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.

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.

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

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.

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.

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

@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.

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

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

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

@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.

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?

@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/

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

@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.

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.

@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.

@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!

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

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

Great @petronny. Thanks for your effort.

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.

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.

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

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.

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

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!

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?

@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.

@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.

@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%?

@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.

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

@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.

@mys_721tx,

• /etc/R/Makeconf http://sprunge.us/2x3uZS?make

• /usr/lib/R/etc/Makeconf same as above.

@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 $@

@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.

@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’
> 

@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?

@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?

@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?

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

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

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

@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

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

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?

@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"

@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.

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 \

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"?

@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.

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.

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

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

Problem solved downgrading glibc from 2.28 to 2.27

Thanks so much for the help

@nessuno, probably something related to glibc.

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

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!

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

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

Updated to 3.5.0.

WARNING: Compilation with icc/ifort is broken.

@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.

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!

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

@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’

@mys_721tx compilation with icc should be fixed now.

@nessuno I'll look into it.

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!

@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?

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?

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

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 :(.

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.

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

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?

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

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

@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.

@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.

Can't compile this.

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