Search Criteria
Package Details: r-mkl 4.2.1-1
Package Actions
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) |
Dependencies (25)
- bzip2 (bzip2-git, bzip2-rustify-git, bzip2-with-lbzip2-symlinks)
- curl (curl-minimal-git, curl-git)
- icu (icu-git-static, icu-git)
- intel-mkl (intel-oneapi-mkl)
- libjpeg (libjpeg-turbo-minimal-git, mozjpeg-git, mozjpeg, libjpeg-turbo-git, libjpeg-turbo)
- libpng (libpng-apng, libpng-minimal-git, libpng-git)
- libtiff (libtiff-git, libtiff-minimal-git, libtiff-lerc, libtiff-maya-git)
- libxmu
- libxt
- ncurses (ncurses-nohex, ncurses-git)
- openmp (openmp-svn, openmp-nvptx)
- pango (pango-ubuntu, pango-minimal-git, pango-git)
- pcre2 (pcre2-svn)
- perl (perl-git)
- readline (readline-athame-git, readline-git)
- unzip (unzip-natspec)
- xz (xz-git)
- zip (zip-natspec)
- zlib (zlib-static, zlib-git, zlib-ng, zlib-ng-compat-git)
- gcc-fortran (gcc-fortran-git, gccrs-fortran-git) (make)
- Show 5 more dependencies...
Required by (3918)
- afni (requires r)
- ants (requires r)
- ants-git (requires r)
- apache-spark (requires r) (optional)
- apache-spark-git (requires r) (optional)
- architect (requires r)
- cantor-git (requires r) (make)
- cantor-git (requires r) (optional)
- data-science-languages-meta (requires r)
- data-science-mkl-meta
- diffoscope-git (requires r) (check)
- diffoscope-git (requires r) (optional)
- dnaa (requires r)
- easena-git (requires r)
- emacs-ess (requires r)
- emacs-ess-git (requires r)
- folding (requires r)
- gatk (requires r)
- gatk-bin (requires r) (optional)
- gcdkit (requires r)
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 PKGBUILDburgerga 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 setsMKLROOT
, but doesn't source it, soMKLROOT
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
owned by:
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:
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: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
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 theBLAS_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 onlymkl_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:
..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:
I was unable to find a solution here, but managed to just copy
lmkl_gf_lp64.so
lmkl_gf_thread
andlmkl_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:
as normal, but running:
I get:
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:in
build()
. EDIT: according to this, usebetween
configure
andmake
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 ofintel-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
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 buildr-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
orr-mkl
update. But I'll usegcc
then since there is no gain when usingicc
.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 togcc
.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 usinggcc
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:blazko commented on 2019-07-15 07:40 (UTC)
Is anyone else facing validity checks problem with parallel_studio_xe?
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) andexport 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:
These were the results:
R 3.5.3 with Intel threading:
top
R 3.6.0 with GNU OpenMP:
top
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 byprofile.d
on login.mys_721tx commented on 2019-05-06 19:36 (UTC)
@alexanderp
LD_LIBRARY_PATH
andLIBRARY_PATH
are not captured inMakeconf
. Therefore/opt/intel/mkl/bin/mklvars.sh
must be sourced before building any package that useslimf
.alexanderp commented on 2019-05-06 19:02 (UTC) (edited on 2019-05-06 19:02 (UTC) by alexanderp)
@mys_721tx,
/etc/R/Makeconf
http://sprunge.us/2x3uZS?make/usr/lib/R/etc/Makeconf
same as above.mys_721tx commented on 2019-05-06 18:51 (UTC)
@alexanderp Could you post your Makeconf?
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:
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:
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.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? :)
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:
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
andmakepkg.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):
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
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
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 togcc
/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.
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)
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
But it gives me errors also in other three files
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 withgcc
. Only when compiling withicc
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)
alexanderp commented on 2017-04-24 18:40 (UTC)
gergi commented on 2017-04-24 07:29 (UTC)
alexanderp commented on 2017-02-16 17:07 (UTC)
adalardo commented on 2017-02-14 11:43 (UTC)
gergi commented on 2017-02-07 15:11 (UTC)
herraiz commented on 2016-11-20 22:42 (UTC)
alexanderp commented on 2016-11-20 21:01 (UTC)
herraiz commented on 2016-11-20 17:41 (UTC)
herraiz commented on 2016-11-20 17:25 (UTC)
hike commented on 2016-11-08 04:26 (UTC)
leonardof commented on 2016-10-03 21:17 (UTC)
leonardof commented on 2016-09-17 20:42 (UTC)
alexanderp commented on 2016-09-17 10:16 (UTC)
leonardof commented on 2016-09-17 03:51 (UTC) (edited on 2016-09-25 16:49 (UTC) by leonardof)
alexanderp commented on 2016-09-09 07:14 (UTC)
GeorgeChao commented on 2016-09-09 06:47 (UTC)
GeorgeChao commented on 2016-09-09 06:47 (UTC)
GeorgeChao commented on 2016-09-09 06:31 (UTC)
AnRe005 commented on 2016-08-07 09:22 (UTC)
greenisagoodcolo commented on 2016-07-12 20:50 (UTC)
AnRe005 commented on 2016-07-05 07:09 (UTC)
lennartv commented on 2016-06-25 19:49 (UTC) (edited on 2016-06-25 20:24 (UTC) by lennartv)
alexanderp commented on 2016-06-22 20:27 (UTC)
wast3 commented on 2016-06-22 19:57 (UTC)
chendaniely commented on 2016-06-19 03:34 (UTC)
greenisagoodcolo commented on 2016-06-17 18:25 (UTC)
AnRe005 commented on 2016-06-17 11:28 (UTC)
alexanderp commented on 2016-06-17 09:28 (UTC) (edited on 2016-06-17 09:28 (UTC) by alexanderp)
greenisagoodcolo commented on 2016-06-17 06:49 (UTC) (edited on 2016-06-17 06:58 (UTC) by greenisagoodcolo)
alexanderp commented on 2016-06-17 00:20 (UTC)
alexanderp commented on 2016-06-16 19:26 (UTC)
greenisagoodcolo commented on 2016-06-16 19:16 (UTC)
AnRe005 commented on 2016-06-16 06:42 (UTC)
alexanderp commented on 2016-06-15 17:18 (UTC)
AnRe005 commented on 2016-06-15 14:57 (UTC)
alexanderp commented on 2016-06-03 11:21 (UTC)
nacnudus commented on 2016-06-03 11:14 (UTC)
nacnudus commented on 2016-06-03 10:06 (UTC)
alexanderp commented on 2016-06-02 18:59 (UTC)
nacnudus commented on 2016-06-02 18:10 (UTC)
alexanderp commented on 2016-06-02 16:27 (UTC)
nacnudus commented on 2016-06-02 14:00 (UTC)
syne commented on 2016-05-17 13:39 (UTC)
alexanderp commented on 2016-05-16 22:04 (UTC)
commented on 2016-05-16 21:17 (UTC)
alexanderp commented on 2016-05-04 12:55 (UTC) (edited on 2016-05-04 12:55 (UTC) by alexanderp)
alexanderp commented on 2016-02-04 23:59 (UTC)
adalardo commented on 2016-02-03 19:52 (UTC)
tetonedge commented on 2016-02-01 14:20 (UTC)
alexanderp commented on 2016-01-20 20:59 (UTC) (edited on 2016-01-20 21:00 (UTC) by alexanderp)
alexanderp commented on 2015-12-20 15:30 (UTC) (edited on 2015-12-20 15:32 (UTC) by alexanderp)
jdarch commented on 2015-09-08 11:54 (UTC)
gabx commented on 2015-09-06 11:42 (UTC)
halfhorn commented on 2015-06-27 17:39 (UTC)
leonardof commented on 2015-06-04 00:06 (UTC)
halfhorn commented on 2015-05-06 08:08 (UTC)
jdarch commented on 2014-12-13 19:52 (UTC)
tetonedge commented on 2014-11-04 03:02 (UTC)
setbl commented on 2014-09-13 14:20 (UTC)
jdarch commented on 2014-09-06 09:31 (UTC)
gabx commented on 2014-09-02 07:39 (UTC)
jdarch commented on 2014-08-30 12:28 (UTC)
jdarch commented on 2014-08-30 10:48 (UTC)
setbl commented on 2014-08-24 13:40 (UTC)
tklee commented on 2014-07-15 02:22 (UTC)
tklee commented on 2014-07-15 02:21 (UTC)
gabx commented on 2014-04-21 11:15 (UTC)
gabx commented on 2014-04-21 11:05 (UTC)
jdarch commented on 2014-01-03 14:32 (UTC)
jdarch commented on 2013-12-24 10:05 (UTC)
zeltak commented on 2013-12-22 12:48 (UTC)
aberkoke commented on 2013-10-24 13:11 (UTC)
jdarch commented on 2013-10-24 12:15 (UTC)
aberkoke commented on 2013-10-24 10:50 (UTC)
jdarch commented on 2013-10-22 02:31 (UTC)
jdarch commented on 2013-10-04 07:23 (UTC)
aberkoke commented on 2013-10-03 12:11 (UTC)
jdarch commented on 2013-09-25 10:22 (UTC)
jdarch commented on 2013-08-05 05:53 (UTC)
matmo commented on 2012-10-17 09:02 (UTC)
commented on 2011-07-10 09:44 (UTC)
commented on 2011-06-26 00:40 (UTC)
giniu commented on 2011-02-14 09:41 (UTC)
giniu commented on 2010-11-10 21:09 (UTC)
giniu commented on 2010-07-30 19:19 (UTC)
giniu commented on 2010-05-06 00:11 (UTC)