SO: Ubuntu 17.04. Until yesterday everything was fine with MPI, then something went wrong. The error is the one on the the title and it comes out running with mpirun -n[n] ./myprogram.
Before Opal the error was with Libmpi.so.12 and I couldn't resolve it despite I tried indicating the LD_LIBRARY_PATH on my .bashrc, as suggested in similar questions here. Then reinstalling OpenMPI the error has changed in this new one, and I don't know how to fix it. Actually the result of apt-file search libmpi.so is:
lam4-dev: /usr/lib/lam/lib/libmpi.so
libopenmpi-dev: /usr/lib/x86_64-linux-gnu/openmpi/lib/libmpi.so
libopenmpi2: /usr/lib/x86_64-linux-gnu/libmpi.so.20
libopenmpi2: /usr/lib/x86_64-linux-gnu/libmpi.so.20.0.2
libopenmpi2: /usr/lib/x86_64-linux-gnu/openmpi/lib/libmpi.so.20.0.2
And ldd returns:
linux-vdso.so.1 => (0x00007ffc415e5000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007fe717956000)
libmpi.so.12 => not found
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fe717738000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fe717371000)
/lib64/ld-linux-x86-64.so.2 (0x000055ccd14f4000)
So the problem still seems to be libmpi.so.12 ? Before reinstalling OpenMPI, libmpi.so.12 was there, MPI couldn't find it, but was there.
[edit]
which mpirun returns:
/usr/bin/mpirun
And apt-file search mpicc returns:
lam4-dev: /usr/bin/mpicc.lam
lam4-dev: /usr/share/man/man1/mpicc.lam.1.gz
libmpich-dev: /usr/bin/mpicc.mpich
libmpich-dev: /usr/share/man/man1/mpicc.mpich.1.gz
libopenmpi-dev: /usr/bin/mpicc.openmpi
libopenmpi-dev: /usr/share/man/man1/mpicc.openmpi.1.gz
libsimgrid-dev: /usr/bin/smpicc
libsimgrid-dev: /usr/share/man/man1/smpicc.1.gz
mpich-doc: /usr/share/doc/mpich-doc/www1/mpicc.html
openmpi-common: /usr/share/openmpi/mpicc-wrapper-data.txt
openmpi-common: /usr/share/openmpi/mpicc.openmpi-wrapper-data.txt
it seems your application was built with an other MPI version (an older Open MPI or an other MPI library such as lam or mpich)
The easiest path is to rebuild your application with the freshly installed Open MPI
[EDIT]
this was diagnosed in the chat, and the root cause was system and user built Open MPI were inadvertently mixed.
once the environment was fixed so only the system Open MPI is used, the issue was resolved.
Related
I've compiled and installed Python 3.10.9 (from .tar) and mariadb-c-connector (from official Github repo) on my Debian 11 (bullseye) machine.
I also installed: ufw, fail2ban, mariadb-server, mariadb-client.
Now if i install mariadb in my Python pipenv and run i got the error: mariadb.OperationalError: This feature is not implemented or disabled.
On my Manjaro it works fine. This is how i create a connection to the database.
def connect(self):
if self.conn:
return
# Connect to MariaDB Platform
try:
self.conn = mariadb.connect(
user=self.user,
password=self.password,
host=self.host,
port=self.port,
database=self.database,
reconnect=True,
)
except mariadb.Error as e:
log.exception(f"Error connecting to MariaDB Platform: {e}")
self.conn = None
return
What i do wrong or what is missing?
Thank you in advance.
Edit:
Output of mariadb_config --cc_version --libs
3.3.4
-L/usr/lib/mariadb/ -lmariadb
Output of ldd /home/USER/.local/share/virtualenvs/PROJEKT/lib/python3.10/site-packages/mariadb/_mariadb.cpython-310-x86_64-linux-gnu.so
linux-vdso.so.1 (0x00007fffa2eec000)
libmariadb.so.3 => /lib/x86_64-linux-gnu/libmariadb.so.3 (0x00007f6911918000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f6911743000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f691173d000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f691171b000)
libssl.so.1.1 => /lib/x86_64-linux-gnu/libssl.so.1.1 (0x00007f6911688000)
libcrypto.so.1.1 => /lib/x86_64-linux-gnu/libcrypto.so.1.1 (0x00007f6911394000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f6911375000)
/lib64/ld-linux-x86-64.so.2 (0x00007f6911988000)
This is the check in source code:
#if MARIADB_PACKAGE_VERSION_ID > 30301
if (mysql_optionsv(self->mysql, MARIADB_OPT_STATUS_CALLBACK, MrdbConnection_process_status_info, self))
goto end;
#endif
It fails, since mysql_optionsv doesn't support the option MARIADB_OPT_STATUS_CALLBACK and returns error CR_NOT_IMPLEMENTED.
Update (after more details were added to the original question):
So it looks like you built (installed) the mariadb module with the correct required Connector/C version (> 3.3.1) , however there is an older Connector/C version in your default library path libmariadb.so.3 => /lib/x86_64-linux-gnu/libmariadb.so.3 (which was likely installed with package libmariadb-dev)
I had the same problem in a docker environment with python 3.11-slim and mariadb 10.11-rc. I also installed mariadb==1.1.5.post3.
I updated the MariaDB Connector/C using the following instruction.
Here's what I did in my Dockerfile
RUN apt-get update && apt-get install -y gcc curl wget
RUN wget https://downloads.mariadb.com/MariaDB/mariadb_repo_setup
RUN chmod +x mariadb_repo_setup
RUN ./mariadb_repo_setup \ --mariadb-server-version="mariadb-10.6"
RUN apt install -y libmariadb3 libmariadb-dev
These commands helped me update the library to the new version.
In my connection code, I also replaced host with the name of the service from the docker-compose.yml file. In my case it will be db
from os import getenv
import mariadb
con = mariadb.connect(
host='db',
user=getenv('DB_USER', default=''),
password=getenv('DB_PASS', default=''),
database=getenv('DB_NAME', default=''),
)
cur = con.cursor()
I hope these commands help resolve the issue in your environment
I'm unable to connect to a Netezza appliance within either R command line or Rstudio. However, I am able to connect to the appliance using isql and nzodbcsql command line tools.
Here's my config so far in Redhat Linux:
1. unixODBC manager installed
2. User environment variables:
LD_LIBRARY_PATH=/usr/local/nz/lib64, where the Netezza library exists. Permissions on the directories are 755
NZ_ODBC_INI_PATH=/common/odbc, where the ODBC config files are located. Permissions are also 755 at this location.
3. Ran "odbcinst -j" to check configuration of ODBC files:
unixODBC 2.3.4
DRIVERS............: /common/odbc/odbcinst.ini
SYSTEM DATA SOURCES: /common/odbc/odbc.ini
FILE DATA SOURCES..: /common/odbc/ODBCDataSources
USER DATA SOURCES..: /common/odbc/odbc.ini
SQLULEN Size.......: 8
SQLLEN Size........: 8
SQLSETPOSIROW Size.: 8
Able to query Netezza using isql and nzodbcsql (select * from _v_dual will return 1 record). Let's pretend the ODBC DNS name is "testdsn"
Attempting to use RODBC in an R session:
library(RODBC)
z = odbcConnect("testdsn")
Warning messages:
1: In RODBC::odbcDriverConnect("DSN=testdsn") :
[RODBC] ERROR: state 01000, code 0, message [unixODBC][Driver Manager]Can't open lib '/usr/local/nz/lib64/libnzodbc.so' : file not found
2: In RODBC::odbcDriverConnect("DSN=testdsn") :
ODBC connection failed
This error usually indicates that the LD_LIBRARY_PATH is not set correctly. I know while I have it set on the command line, it's not set for R, so I set it in Renviron.site config file.
Sys.getenv("LD_LIBRARY_PATH")
[1] "/lib64:/usr/include:/usr/lib64:/usr/local/nz/lib64"
I have also run a ldd on the libnzodbc.so file, and am not seeing any linking problems:
system("ldd /usr/local/nz/lib64/libnzodbc.so")
linux-vdso.so.1 => (0x00007fff1fdce000)
libc.so.6 => /lib64/libc.so.6 (0x00007f26ede93000)
libm.so.6 => /lib64/libm.so.6 (0x00007f26edb91000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f26ed975000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f26ed771000)
libkrb5.so.3 => /usr/local/nz/lib64/libkrb5.so.3 (0x00007f26ee58a000)
libkrb5support.so.0 => /usr/local/nz/lib64/libkrb5support.so.0 (0x00007f26ed664000)
libcom_err.so.3 => /usr/local/nz/lib64/libcom_err.so.3 (0x00007f26ed561000)
libk5crypto.so.3 => /usr/local/nz/lib64/libk5crypto.so.3 (0x00007f26ed41e000)
/lib64/ld-linux-x86-64.so.2 (0x00007f26ee54c000)
libresolv.so.2 => /lib64/libresolv.so.2 (0x00007f26ed205000)
I'm able to query via the unixODBC and Netezza command line tools, but can't query via R or Rstudio. As far as I can tell, I have the R environment variables set up correctly to find the library path, but it still can't find the file. Does anyone know if I'm missing anything else?
R version: 3.4.4
Netezza driver version: 3.51
Rehat version: 7.6
I figured out how to get it working. For some reason R seems to be ignoring the entries in LD_LIBRARY_PATH. Instead, I added the library location using ldconfig. Once it was added there and loaded (verified by running ldconfig -p), I was able to query in R.
I was just on vacation for a month so am unable to say the exact point at which this happened, but R from the official Arch repos is now unable to start, citing
/usr/lib64/R/bin/exec/R: error while loading shared libraries:
libgfortran.so.3: cannot open shared object file: No such file or directory
I thought that perhaps a symlink was improperly placed or destroyed, so I looked in /usr/lib to try to find it:
ls -halt /usr/lib/libgfortran.so.*
lrwxrwxrwx 1 root root 20 May 16 03:01 /usr/lib/libgfortran.so.4 -> libgfortran.so.4.0.0
-rwxr-xr-x 1 root root 7.1M May 16 03:01 /usr/lib/libgfortran.so.4.0.0
Has libfortran.so.3 been superseded by libgfortran.so.4 in Arch? If so, are there any possible workarounds for getting R to run with an older version?
pacman -Qi r
Name : r
Version : 3.4.0-2
Description : Language and environment for statistical computing and graphics
Architecture : x86_64
URL : http://www.r-project.org/
Licenses : GPL
Groups : None
Provides : None
Depends On : blas lapack bzip2 libpng libjpeg libtiff ncurses pcre readline zlib perl gcc-libs libxt libxmu pango xz desktop-file-utils zip unzip
Optional Deps : tk: tcl/tk interface [installed]
texlive-bin: latex sty files [installed]
Required By : None
Optional For : graphviz
Conflicts With : None
Replaces : None
Installed Size : 58.04 MiB
Packager : Evangelos Foutras <evangelos#foutrelis.com>
Build Date : Tue 25 Apr 2017 05:04:31 AM EDT
Install Date : Tue 20 Jun 2017 12:27:06 PM EDT
Install Reason : Explicitly installed
Install Script : No
Validated By : Signature
Edit: If anyone else comes across this, the r-devel AUR correctly compiles and runs, so hopefully on the next version bump the issue will be resolved.
Indeed, gfortran 7 bumps the ligfortran version to version 4. See http://gcc.1065356.n8.nabble.com/patch-fortran-PR77828-Linking-gfortran-7-compiled-program-with-libgfortran-of-5-x-allowed-but-crashes-td1311625.html It is not backwards compatible and some APIs have changed.
If you install an older version of gfortran you will get libgfortran.so.3. It is completely fine to have multiple versions in your system. Maybe there is a way how to rebuild R for version 4, but it will be possibly more work. See other answers how to rebuild the software https://stackoverflow.com/a/50744705/721644
I work on a software named pyferret which needs libgfortran.so.3. I am running fedora 27 whose package manager installs gfortran 7 (A higher version) by default. This produces the shared object libgfortran.so.4 in /usr/lib64. Another Linux system running Ubuntu 16.04.3, however has libgfortran.so.3. I copied it to my system in ~/pkgs/libs and ran the application as
export LD_PRELOAD=/home/vasu/pkgs/libs/libgfortran.so.3:/home/vasu/pkgs/libs/libopenblas.so.0;pyferret
This worked without the above error.
There are many packages in R dependent upon GCC Fortran. Some of those have not been updated to compile against the new GCC, while some package get updated that are dependent upon these, deldir and robustbase are two examples.
Check your warnings and are install any of the packages that fail to load then execute the upgrade.
The problem may come from some AUR packages that haven't been rebuild after the GCC update. In my personal case, it was probably the package openblas-lapack that messed around (see https://bbs.archlinux.org/viewtopic.php?id=236900). So there might be no need to install any former version of GCC.
What I did was to:
update all my AUR packages (yaourt -Syua)
then rebuild R (pacman -S r)
and it worked again.
This issue periodically occurs whenever libgfortran receives an incompatible soname bump, mostly because in the R world it is quite common for blas/lapack to be replaced by alternative implementations from the AUR.
The important thing to note here is that it is not actually R that has the error.
Minor disclaimer here: I'm speaking with my official Arch Linux bugwrangler hat on here, and this is how I would try to track down this sort of issue. (It's also how I check whether a bug report should be closed as invalid.)
Using my handy-dandy Arch Linux bugwrangler utility tool pkg-list-linked-libraries (it does what it says on the tin):
$ pkg-list-linked-libraries r libgfortran.so
==> checking linked libraries for r-3.5.1-2-x86_64.pkg.tar.xz ...
==> ERROR: No file in r-3.5.1-2-x86_64.pkg.tar.xz is linked to libgfortran.so
So, if it is not coming from R itself, where is it coming from? Using the tool lddtree (from pax-utils) to show not just the libraries needed by the executable (like ldd does), but to also show you, in tree format, why they are needed:
$ lddtree /usr/lib/R/bin/exec/R
/usr/lib/R/bin/exec/R (interpreter => /lib64/ld-linux-x86-64.so.2)
libR.so => /usr/lib/R/lib/libR.so
libblas.so.3 => /usr/lib/libblas.so.3
libgfortran.so.5 => /usr/lib/libgfortran.so.5
libquadmath.so.0 => /usr/lib/libquadmath.so.0
libgcc_s.so.1 => /usr/lib/libgcc_s.so.1
libm.so.6 => /usr/lib/libm.so.6
libreadline.so.7 => /usr/lib/libreadline.so.7
libncursesw.so.6 => /usr/lib/libncursesw.so.6
libpcre.so.1 => /usr/lib/libpcre.so.1
liblzma.so.5 => /usr/lib/liblzma.so.5
libbz2.so.1.0 => /usr/lib/libbz2.so.1.0
libz.so.1 => /usr/lib/libz.so.1
libtirpc.so.3 => /usr/lib/libtirpc.so.3
libgssapi_krb5.so.2 => /usr/lib/libgssapi_krb5.so.2
libkrb5support.so.0 => /usr/lib/libkrb5support.so.0
libkeyutils.so.1 => /usr/lib/libkeyutils.so.1
libresolv.so.2 => /usr/lib/libresolv.so.2
libkrb5.so.3 => /usr/lib/libkrb5.so.3
libk5crypto.so.3 => /usr/lib/libk5crypto.so.3
libcom_err.so.2 => /usr/lib/libcom_err.so.2
librt.so.1 => /usr/lib/librt.so.1
libdl.so.2 => /usr/lib/libdl.so.2
libicuuc.so.62 => /usr/lib/libicuuc.so.62
libicudata.so.62 => /usr/lib/libicudata.so.62
libstdc++.so.6 => /usr/lib/libstdc++.so.6
libicui18n.so.62 => /usr/lib/libicui18n.so.62
libgomp.so.1 => /usr/lib/libgomp.so.1
libpthread.so.0 => /usr/lib/libpthread.so.0
libc.so.6 => /usr/lib/libc.so.6
The relevant bit here is the beginning:
/usr/lib/R/bin/exec/R (interpreter => /lib64/ld-linux-x86-64.so.2)
libR.so => /usr/lib/R/lib/libR.so
libblas.so.3 => /usr/lib/libblas.so.3
libgfortran.so.5 => /usr/lib/libgfortran.so.5
And if I delete the libgfortran library because this is a testing chroot and I don't care what happens to it, I see:
/usr/lib/R/bin/exec/R (interpreter => /lib64/ld-linux-x86-64.so.2)
libR.so => /usr/lib/R/lib/libR.so
libblas.so.3 => /usr/lib/libblas.so.3
libgfortran.so.5 => None
This clearly shows that it is libblas.so that has an error finding libgfortran.so, and from there you can check to see what pacman package owns the broken libblas.so -- and if it is truly an official repository package, then you can report a bug to get it fixed, if not, then now you know which AUR package to recompile yourself.
I can't say for sure about Arch-Linux, but multiple versions of the gfortran libraries are available on the standard set of repos included with apt on Ubuntu.
When changing to 18.04 (LTS) I had to install the previous version alongside the default version 4 of the libraries.
For me the following command solved this issue:
sudo apt-get install libgfortran3
Rebuilding all packages in R may not solve the issue if your package hasn't been maintained in a while, as was my case.
There are a couple of related threads here, but the gist of my attempt to connect to Vertica with R over OpenCPU and vRODBC is:
I started with RJDBC, which works fine in RStudio (even the server RStudio edition), but OpenCPU/rApache doesn't like it. rJava on OpenCPU
I installed the vRODBC package which is a derivative of RODBC and I successfully queried Vertica from both the CMD Line using isql and from RStudio Server using the DSN and odbcConnect('myDSNName') Installing vRODBC
When I compile the app with code that works on RStudio Server I get a connection error when trying to run it over OpenCPU (pulled from the console):
It works from the RStudio Server
> vertica = odbcConnect("VerticaDSN")
> data = sqlQuery(vertica, query)
> data
TDIDCount
1 3015
But not from the Opencpu App I created
//From Console Output
[vRODBC] ERROR: state 01000, code 0, message [unixODBC][Driver Manager]Can't open lib '/opt/vertica/lib64/libverticaodbc.so.6.1.3' : file not found
Warning message:
ODBC connection failed
[1] -1
I checked this path and it clearly does exist. I found another question which says that this error is caused by a dependency that can't be loaded for the libverticaodbc.so library so I tried to follow steps to see which library I might not have had permissions for with the opencpu user to no avail. Can't open lib with UnixODBC
$ sudo su - opencpu
$ ldd /opt/vertica/lib64/libverticaodbc.so.6.1.3
linux-vdso.so.1 => (0x00007fff5cd10000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f16a30cc000)
libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x00007f16a2eb1000)
libcrypt.so.1 => /lib/x86_64-linux-gnu/libcrypt.so.1 (0x00007f16a2c77000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f16a2a59000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f16a2755000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f16a244e000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f16a2238000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f16a1e73000)
/lib64/ld-linux-x86-64.so.2 (0x00007f16a4854000)
$
I'm close... very close... I can feel it... just gotta get some shadowy environment variable or permissions fixed so that OpenCPU can correctly find the ODBC drivers and then I'll have more R+webApp glory propelling me forward!
I am having a matrix error when using the computer cluster at my university that I cannot reproduce on my local machine. I think it might be due to a difference of matrix libraries (BLAS, LAPACK, ATLAS, etc.). I don't know much about these libraries other than what I've read here, but I'm thinking there should be a way to get R to tell me which matrix libraries it was installed with (i.e. which ones it's using), analogous to sessionInfo() to tell me which version of R packages it's using.
Though there may not be an explicit R function for this, perhaps you can capitalize on shell commands (e.g., file and ldd) to get some clues without requiring rebuilding R nor root access on the cluster:
(rpath <- Sys.which("R"))
# R
# "/usr/bin/R"
To make sure that ldd will work, see what type of file it is:
system2("file", rpath)
# /usr/bin/R: Bourne-Again shell script, ASCII text executable
If yours shows an actual executable (such as ELF 64-bit LSB executable, x86-64, ...), then skip this one step.
script <- readLines(rpath)
script[grepl("/bin/", script)]
# [1] "#!/bin/bash"
# [2] " if [ -x \"/usr/${libnn}/R/bin/exec/R\" ]; then"
# [3] " elif [ -x \"/usr/${libnn_fallback}/R/bin/exec/R\" ]; then"
# [4] "## some systems have a more portable sed, e.g. /usr/xpg4/bin/sed on Solaris,"
# [5] "SED=/bin/sed"
# [6] " exec sh \"${R_HOME}/bin/Rcmd\" \"${#}\" ;;"
# [7] "R_binary=\"${R_HOME}/bin/exec${R_ARCH}/R\""
This tells me that the actual executable is /usr/lib/R/bin/exec/R (or /usr/lib64/...). It is taking some inference, but it's a step. This is working for me with R-3.3.2 on ubuntu, so I can only assume it'll be similar on different OSes. If this is uninformative, you can also grep for "/lib" or "/exec" (or just examine the whole script file for other clues).
Once you know the path called by the script (or if it isn't a script to begin with), find the shared library dependencies:
system2("ldd", "/usr/lib/R/bin/exec/R")
# linux-vdso.so.1 => (0x00007ffcfadcd000)
# libR.so => /usr/lib/R/lib/libR.so (0x00007f746f615000)
# libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f746f3eb000)
# libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f746f025000)
# libblas.so.3 => /usr/lib/libblas.so.3 (0x00007f746eda8000)
# libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f746eaa2000)
# libreadline.so.6 => /lib/x86_64-linux-gnu/libreadline.so.6 (0x00007f746e85b000)
# libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007f746e61d000)
# liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x00007f746e3fb000)
# libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0 (0x00007f746e1ea000)
# libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f746dfd1000)
# librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f746ddc9000)
# libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f746dbc4000)
# libgomp.so.1 => /usr/lib/x86_64-linux-gnu/libgomp.so.1 (0x00007f746d9b5000)
# /lib64/ld-linux-x86-64.so.2 (0x0000560abd5fa000)
# libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 (0x00007f746d78b000)
The 5th line of this output suggests that R is using the BLAS library, specifically libblas3.
As far as I am aware there isn’t a specific function (especially not in base R) that will give you the BLAS version. R will most likely use the standard library that comes with your system (unless someone built it from source with a specific BLAS version).
You’d have to do it from the terminal, type
locate libblas.so
It’s probably going to be in /usr/lib/libblas.so or /usr/lib64/libblas.so, and the location is probably a symlink. So follow the links
ls -l /usr/lib/libblas.so
If you want to to change the symbolic links to point to a different BLAS library, you can do
update-alternatives --config libblas.so.3gf
and select the version you want to use. This post explains it very nicely in more detail: https://www.r-bloggers.com/for-faster-r-use-openblas-instead-better-than-atlas-trivial-to-switch-to-on-ubuntu/
Another way to definitely know what version you are using, would be to install whatever implementation of BLAS you want – for example OpenBLAS, and then replace the standard R BLAS library with a symlink to your new library. Make sure to install R with --with-shared-blas option, as explained in here: https://cran.r-project.org/doc/manuals/r-release/R-admin.html#BLAS
Then you just need to:
# navigate to your R directory
cd …/path-to-R-installation/lib/R/lib
# backup the original
mv libRblas.so libRblas.backup
# create simlink
ln –s …/path-to-new-0blas-library/new-lib.so libRblas.so
Is a bit of googling enough?:
http://www.stat.cmu.edu/~nmv/2013/07/09/for-faster-r-use-openblas-instead-better-than-atlas-trivial-to-switch-to-on-ubuntu/