When I try to install certain packages (imputeTS
) that need libRblas.so
which AFAIK refers to OpenBLAS I get an error that it was not found:
Error in dyn.load(file, DLLpath = DLLpath, ...) :
unable to load shared object '/home/jay/R/x86_64-pc-linux-gnu-library/4.2/fracdiff/libs/fracdiff.so':
libRblas.so: cannot open shared object file: No such file or directory
Calls: <Anonymous> ... asNamespace -> loadNamespace -> library.dynam -> dyn.load
Execution halted
However, the sessionInfo()
indicates, that R actually finds it.
> sessionInfo()
R version 4.2.1 (2022-06-23)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu 22.04 LTS
Matrix products: default
BLAS: /usr/lib/x86_64-linux-gnu/openblas-pthread/libblas.so.3
LAPACK: /usr/lib/x86_64-linux-gnu/openblas-pthread/libopenblasp-r0.3.20.so
I learned from this thread that "maybe … another version of R [was built] and it sits in … [the] $PATH before the packaged version", which is likely to be the case; my former R version 4.2.0
was a self-compiled one, and I removed it by downloading the source again and ./configure
– make uninstall
. This one is installed via sudo apt install r-base-core
, though. Probably now there is a mess somewhere. Unfortunately the cited thread was solved differently, and I’m looking now for the respective conclusion.
Here is some more information:
whereis R
gives
~$ whereis R
R: /usr/bin/R /usr/lib/R /usr/lib64/R /etc/R /usr/local/lib/R /usr/share/R /usr/share/man/man1/R.1.gz
From the respective files from the error message, using sudo find ~ -name '<file>'
, fracdiff.so
was found, whereas libRblas.so
wasn’t.
~/R/x86_64-pc-linux-gnu-library/4.2/fracdiff/libs/fracdiff.so
I already tried,
~$ sudo apt install libopenblas-dev
but obviously it is installed.
libopenblas-dev is already the newest version (0.3.20+ds-1).
Following the suggestions of this, libRlapack.so
and libRblas.so
obviously don’t exist on my system, and the other suggestion just gives:
~$ sudo update-alternatives --config libblas.so
update-alternatives: error: no alternatives for libblas.so
2
Answers
Some comments have put me on the right track and helped me to solve the problem—I will briefly summarize.
Since a dependencies issue was suspected, I installed the package from which the error message originated (
fracdiff
in this case) and tried again to install the target package. The error reoccurred, but came from a different package indicating cascading problems. Weirdly enough, I definitely knew the package was installed, so I felt my initial suspicion confirmed, that I might have made a mess with thelibs
folders when updating R as described in the OP.Since I could assume that this would happen again and again, the conclusion was to uninstall R completely, and this time the packages as well, and then reinstall everything. Now I could install the target package among others without any problems.
Fortunately, this is quite easy on Linux. Also all packages can be reinstalled relatively unattended. The how-to's are spread out over several threads and sites, I'll put the strings together, adding the references.
Here is what I did in R and in Bash (you will need
su/sudo
):The locations might differ from yours.
apt
) 4This runs for a while. Note that only packages that can be found in repositories are installed.
There should never be a "requirement" for
libRblas.so
. In short, R allows you to build with the BLAS and LAPACK (subset of) sources it shipts, you then get thislibRblas.so
. Or you can use the system BLAS and LAPACK libraries, which the Debian (and hence Ubuntu) package I am responsible for has been doing for probably close to twenty years, and which allows you to switch BLAS installation (Atlas, OpenBLAS, MKL, back in the day also Goto, …).As a demonstration, I just launched a suitable Ubuntu 22.04 Docker container based on r2u as it combines having R pre-made (using my
r-base-core
package with the external BLAS linkage) as well as the (awesome !!) ability to take all of CRAN as Ubuntu binaries (see r2u for more). In short:after which we can indeed launch R and load it just fine:
It uses external BLAS/LAPACK "by design":
So I think this may be self-imposed by a combination of you having maybe compiled R locally plus the
imputeTS
not dealing well with that (it should, it may be a bug). But I hope this also shows that this can be so much easier too.If you have more detailed follow-up questions please come to the
r-sig-debian
list which is friendly, no-sensense and low-volume.PS For completness, the container’s
sessionInfo()
in a fresh session:PPS A ‘live’ demo in one animated gif is in this tweet (tweeted as one cannot attach gifs over 2mb here).