Updating installed packages for R-3.5.2 (in Slackware-14.2) the "later" package fails to load because of this error:
/usr/lib/R/library/later/libs/later.so: undefined symbol: __atomic_fetch_add_8,
Web searches and folks on the r-help mail list were not able to resolve this issue.
Earlier versions of "later" had no problems installing and updating.
All suggestions will be followed up.
Issue #73 on github discusses that on some platforms, one needs to add a flag -latomic even though std::atomic is part of the C++11 standard library.
Assuming you have C++11 installed on your Slackware 14.2, you should be able to:
git clone https://github.com/r-lib/later.git
nano later/src/Makevars # or whatever editor you prefer
# Change `PKG_LIBS = -pthread` to `PKG_LIBS = -pthread -latomic`
sudo R CMD INSTALL later
Update December 2019:
With the latest version of later, it now is:
git clone https://github.com/r-lib/later.git
nano later/src/Makevars.in # or whatever editor you prefer
# Change `PKG_LIBS = -pthread #extra_pkg_libs#` to `PKG_LIBS = -pthread -latomic #extra_pkg_libs#`
sudo R CMD INSTALL later
Related
I just migrated things over from my old mac to my my new mac (Intel to Apple Silicon), installed the latest version of R, ran brew upgrade, and began updating R packages. Many needed to be reinstalled, some from source. I bumped into several issues.
Library linkages not being found (e.g., Mac OS Big Sur R compilation error: ld: framework not found CoreFoundation)
for CRAN packages, having the CRAN mirror selection pop up in a weird X11 GUI window instead of a numeric selection in the R console (which was the previous behavior).
I didn't really want to troubleshoot each library issue. I got the sense that ~/.R/Makevars and ~/.Rprofile might need to be edited. What did I need to do to make these problems go away?
A few resources were helpful, but some seemed out of date or incomplete. Here is my attempt to give a full step-by-step recreation of what I think worked, and I will edit as needed while I get my new system up and running.
Based largely on the recommendations here, I edited the Makevars file as follows:
In the shell:
vi ~/.R/Makevars
I then hit i (for insert) and deleted Everything that was there. I then added:
LDFLAGS += -L/opt/homebrew/opt/libomp/lib
CPPFLAGS += -I/opt/homebrew/opt/libomp/include
FLIBS =-L/opt/homebrew/opt/gfortran/lib
F77 = /opt/homebrew/bin/gfortran
FC = /opt/homebrew/bin/gfortran
CFLAGS = -I/opt/homebrew/include
CPPFLAGS = -I/opt/homebrew/include
CXXFLAGS = -I/opt/homebrew/include
To save, I hit esc and then :x to save and close.
AFAIK, this resolved the issues with library finding/loading/linking, and I have installed several packages from source without error now.
To deal with the annoying pop-out GUI window to select the CRAN mirror, I edited the ~/.Rprofile (also using vi as described above) to read:
local({r <- getOption("repos")
r["CRAN"] <- "https://cloud.r-project.org"
options(repos=r)
})
options(menu.graphics = FALSE)
This was based on the best looking answers to this old but still important question
While trying to install R from source, I ran into linker issues, in particular: undefined reference to 'u_getVersion_58
I found limited information on this error (eg, this post on the RStudio forum).
Despite running apt-get build-dep, these issues persisted.
It is apparent from these comments by Dirk Eddenbuettel that it relates to libicu versions. I have libicu version 60, while R 3.6.0 and similar recent versions seem to require version 58.
We can install a previous version of libicu from source as follows:
wget http://download.icu-project.org/files/icu4c/58.2/icu4c-58_2-src.tgz
tar -xf icu4c-58_2-src.tgz
cd icu
make
make install
However, make is likely to run into a compilation error due to missing xlocale.h. As indicated on this github post, this can be solved by running ln -s /usr/include/locale.h /usr/include/xlocale.h, as xlocale.h is just a subset of locale.h which was removed from glibc recently. After this, make and make install should succeed for icu version 58, and following that, for R.
Periodically – I think whenever I update R – I have problems installing packages from source on my 64-bit Windows machine.
Today I'm trying to install a package using devtools::install_github(). The installation proceeded fine on my laptop, but my not on my desktop, which can install the package under *** arch - i386, but under *** arch - x64, which reports the error message
C:/PROGRA~1/R/R-34~1.4/bin/x64/R.dll: file not recognized: File format not recognized
The command that caused the error is
C:/Rtools/mingw_32/bin/g++ -shared -s -static-libgcc -o PACKAGENAME.dll [...]
I believe that the error is arising because R is using mingw_32 to attempt to compile a 64-bit package. The question is, where can I tell R to use mingw_64? I've already checked all the places that I can recall:
R-3.4.4/etc/x64/Makeconf states
BINPREF ?= c:/Rtools/mingw_64/bin/
My system PATH (verified from within R using Sys.getenv('PATH')) includes mingw_64 ahead of mingw_32.
R must be looking somewhere else to decide which compiler to use... but where?
Via R CMD check not looking for gcc in Rtools directory:
R was looking in C:/Users/MYUSERNAME/Documents/.R/Makevars for the value of BINPREF. Deleting the contents of this file removed the incorrect location.
$RPATH/etc/i386/Makeconf is re-created with each new installation of R, and contains the line
BINPREF ?= c:/Rtools/mingw_32/bin/.
The ?= operator will set the value of BINPREF if it is not already set, as it was in the Makevars file mentioned above. So replacing ?= with = will work until a new version of R is installed and the Makeconf file is overwritten – updating, or uninstalling, R will not modify the Makevars file in the User directory.
If you start digging from devtools::install_github, it will lead you through the following functions:
devtools::install_github
devtools:::install_remotes
devtools:::try_install_remote
devtools:::install_remote
devtools:::install
devtools:::check_build_tools
devtools:::setup_rtools
devtools:::scan_path_for_rtools
And when you run the following code:
devtools:::scan_path_for_rtools(TRUE)
devtools:::setup_rtools(debug=TRUE)
Most likely, it is saying that Rtools is not currently installed. (Yes, a bit counterintuitive given that you already have it installed in C:/Rtools but maybe not registered in registry)
To fix it, you will need to run (which is in essence the solution in Rtools is not being detected from RStudio)
Sys.setenv(PATH=paste0("C:\\Rtools\\bin;", Sys.getenv("PATH")))
devtools:::set_rtools_path(structure(list(path="c:/Rtools/mingw_64/bin", version=3.4), class="rtools"))
devtools:::set_rtools_path(structure(list(path="c:/Rtools/mingw_32/bin", version=3.4), class="rtools"))
Please let me know if this works.
BINPREF ?= c:/Rtools/mingw_64/bin/
remove ? before =
Conda was used to install R in my centos 7 sysytem. conda install r
the version of installed r is r-3.4.1.
However, when I use r, there have a error output. "/usr/local/bin/miniconda3/lib64/R/bin/exec/R: error while loading shared libraries: libtinfow.so.6: cannot open shared object file: No such file or directory"
Some tests have been used according to search by google use the keyword "libtinfow.so.6".
Only two information can be found. They have no help to me.
enter image description here
I had the same problem on a recent centos installation. But I think this has nothing to do with centos, but rather to misconfiguration related to different R packages version. To solve the problem, I just uninstall all the R related packages and gxx and gcc packages using "conda uninstall ". Than I installed R using "conda install -c r r", which force to install gcc and gxx within the same process.
I'm trying to build the R openssl package and link it to an openssl library that is a newer version than the one in the systemwide lib64 directory.
The Makevars file simply has:
KG_CPPFLAGS=#cflags#
PKG_LIBS=#libs#
I can specify my local library by passing a custom library path in the configure script. But when I issue R CMD INSTALL, the linking command begins with
gcc -std=gnu99 -shared -L/usr/local/lib64 -o openssl.so [...objects...] -Lmy/path/here -lssl -lcrypto
As a result, the linker finds the wrong library (the one in /usr/local/lib64) instead of mine.
How do I adjust the linking command so that it looks for the library first in my directory, instead of the system folder.
(Background: I don't have root access and this older version of CentOS (5) doesn't support openssl v1, so I built v1 myself just to compile the R package. But I'm stuck at the linking stage due to whatever magic is happening by R CMD INSTALL.)
I solved this by passing arguments to R CMD INSTALL. I.e.:
R CMD INSTALL . --configure-vars="INCLUDE_DIR=$HOME/local/include LIB_DIR=$HOME/local/lib64"
But this varies for each package. There's no general solution.
Instead, read config and src/Makefile.in.