devtools installation issues MacOS gcc

I've recently updated to R 4.0.2 and am having horrific issues with devtools installation. I am getting the following error:

# approach 1
install.packages("devtools")

trying URL 'https://cran.rstudio.com/bin/macosx/contrib/4.0/devtools_2.3.2.tgz'
Content type 'application/x-gzip' length 337605 bytes (329 KB)
==================================================
downloaded 329 KB

library(devtools)

Error: package or namespace load failed for ‘devtools’ in dyn.load(file, DLLpath = DLLpath, ...):
 unable to load shared object '/Library/Frameworks/R.framework/Versions/4.0/Resources/library/pkgload/libs/pkgload.so':
  dlopen(/Library/Frameworks/R.framework/Versions/4.0/Resources/library/pkgload/libs/pkgload.so, 6): Library not loaded: /usr/local/opt/gcc/lib/gcc/9/libgomp.1.dylib
  Referenced from: /Library/Frameworks/R.framework/Versions/4.0/Resources/library/pkgload/libs/pkgload.so
  Reason: image not found

# approach 2
install.packages("devtools", type = "source")
trying URL 'https://cran.rstudio.com/src/contrib/devtools_2.3.2.tar.gz'
Content type 'application/x-gzip' length 373387 bytes (364 KB)
==================================================
downloaded 364 KB

* installing *source* package ‘devtools’ ...
** package ‘devtools’ successfully unpacked and MD5 sums checked
** using staged installation
** R
** inst
** byte-compile and prepare package for lazy loading
Error in dyn.load(file, DLLpath = DLLpath, ...) : 
  unable to load shared object '/Library/Frameworks/R.framework/Versions/4.0/Resources/library/pkgload/libs/pkgload.so':
  dlopen(/Library/Frameworks/R.framework/Versions/4.0/Resources/library/pkgload/libs/pkgload.so, 6): Library not loaded: /usr/local/opt/gcc/lib/gcc/9/libgomp.1.dylib
  Referenced from: /Library/Frameworks/R.framework/Versions/4.0/Resources/library/pkgload/libs/pkgload.so
  Reason: image not found
Calls: <Anonymous> ... asNamespace -> loadNamespace -> library.dynam -> dyn.load
Execution halted
ERROR: lazy loading failed for package ‘devtools’
* removing ‘/Library/Frameworks/R.framework/Versions/4.0/Resources/library/devtools’
Warning in install.packages :
  installation of package ‘devtools’ had non-zero exit status

The downloaded source packages are in
	‘/private/var/folders/_5/rq2_d4m14rj0c2vsh_8mbhgh0000gn/T/Rtmp3x5lzg/downloaded_packages’

This makes sense: I actually have gcc10 instead of gcc9, installed via homebrew:

ls /usr/local/opt/gcc/lib/gcc/
drwxr-xr-x  47 darya  staff  1504 19 Aug 13:18 10

I am not sure why R is not seeing that more recent version of gcc? Moreover, astoundingly, Rcpp works (and I've tested it with the basic code in the documentation vignette, so it not only loads, but also actually works).

How do I fix this? Thanks in advance!!!

is the Makefile signifying that it was expecting to find version 9. Version 10 won't do. It is possible, of course, to edit the Makefile, but probably not how most users should be spending time.

Hi Darya,
It looks like the pkgload package isn't pointing to your current gcc installation.

To answer your other questions first, I think that without a ~/.R/Makevars file, R will default to the clang identified by typing "which clang" in the terminal (Default compilation settings for R are in
/Library/Frameworks/R.framework/Versions/4.0/Resources/etc/Makeconf). This is probably why R isn't picking up your current installation of gcc10.

The easiest way to fix it is to re-install "pkgload" as a binary as it is a
dependency of devtools, and then re-installing devtools.

The longer way is to first create or update your ~/.R/Makevars file to use gcc-10 from homebrew, and then reinstalling pkgload and devtools from source.
An example of my Makevars file is below.

GCC_LOC = /usr/local/opt/gcc
CC = $(GCC_LOC)/bin/gcc-10
CFLAGS=-g -O3 -Wall -pedantic -std=gnu99 -mtune=native -pipe $(LTO)
CPICFLAGS = -fPIC
CPPFLAGS = -I/usr/local/include
CXX = $(GCC_LOC)/bin/g++-10
CXXCPP = $(CXX) -E
CXXSTD = -std=gnu++11
CXXFLAGS = -Wall -g -O2 $(LTO)
CXXPICFLAGS = -fPIC
CXX98 = $(GCC_LOC)/bin/g++-10
CXX98FLAGS = -Wall -g -O3
CXX98PICFLAGS = -fPIC
CXX98STD = -std=gnu++98
CXX11 = $(GCC_LOC)/bin/g++-10
CXX11FLAGS = -Wall -g -O3
CXX11PICFLAGS = -fPIC
CXX11STD = -std=gnu++11
CXX14 = $(GCC_LOC)/bin/g++-10
CXX14FLAGS = -Wall -g -O3
CXX14PICFLAGS = -fPIC
CXX14STD = -std=gnu++14
CXX17 = $(GCC_LOC)/bin/g++-10
CXX17FLAGS = -Wall -g -O3
CXX17PICFLAGS = -fPIC
CXX17STD = -std=gnu++17
CXX_VISIBILITY = 
FC = gfortran
FCFLAGS = -Wall -g -O3 $(LTO)
## additional libs needed when linking with $(FC), e.g. on some Oracle compilers
FCLIBS = 
F77 = gfortran
F77_VISIBILITY = 
FFLAGS = -g -O3 $(LTO)
FLIBS =  -L/usr/local/gfortran/lib/gcc/x86_64-apple-darwin18/8.2.0 -L/usr/local/gfortran/lib -lgfortran -lquadmath -lm
LDFLAGS=-L/usr/local/opt/gettext/lib -L$(GCC_LOC)/lib -Wl,-rpath,$(GCC_LOC)/lib

SHLIB_OPENMP_CFLAGS= -fopenmp
SHLIB_OPENMP_CXXFLAGS= -fopenmp
SHLIB_OPENMP_FCFLAGS= -fopenmp
SHLIB_OPENMP_FFLAGS= -fopenmp

PKG_LIBS= $(SHLIB_OPENMP_CFLAGS) $(LAPACK_LIBS) $(BLAS_LIBS) $(FLIBS)
2 Likes

Huzzah! This worked - thank you! Having said that: do you have any good resources on learning how to write those makefiles/what things mean in them?

2 Likes

I've found bits and pieces all over the place but thecoatlessprofessor's blog
is pretty good: https://thecoatlessprofessor.com/programming/cpp/r-compiler-tools-for-rcpp-on-macos/ and just google searching using rcpp and
Makevars, i.e., https://stackoverflow.com/questions/43597632/understanding-the-contents-of-the-makevars-file-in-r-macros-variables-r-ma

Happy compiling :slight_smile:

1 Like

@jrmuirhead can weigh in on the advantages of making a major intellectual capital and time investment in optimizing a macOS toolchain. I'll address the disadvantage

As a user of R, it's time better spent using R.

Members of the R Core Development Team, notably Simon Urbanek, devote considerable time to compiling macOS binaries from R package source code. Oftentimes, little is involved, because the dependencies are simple and the source code will compile for any user with a reasonably current set of the XCode CLI tools. Other times, however, it takes someone who is probably on a first-name basis with the Gods of Unix to figure out. In between are mere mortals who struggle getting it right.

On other Unix flavors, such as the Debians, compilation seldom fails for any reason other than a missing system library, which is easy to fix. That's because source packages aren't released if they don't compile in Linux.

This intro gives a flavor of makefiles at their simplest. Production code is often hundreds of lines long.

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.

If you have a query related to it or one of the replies, start a new topic and refer back with a link.