I'm trying in vain to compile the armadillo linear algebra library for windows. Using the armadillo-4.200.0 source, I have Rtools-3.1 installed and in the path, msys from MinGW installed.
Because my ultimate goal is to use Rcpp and RcppArmadillo, my thought is that I need to use the same compiler for making armadillo as will be used to compile my Rcpp/RcppArmadillo files. Unfortunately, when trying to compile armadillo:
$ ./configure
[...snip...]
-- The CXX compiler identification is unknown
-- Check for working CXX compiler: cl
CMake Warning at CMakeLists.txt:3 (PROJECT):
To use the NMake generator, cmake must be run from a shell that can use the
compiler cl from the command line. This environment does not contain
INCLUDE, LIB, or LIBPATH, and these must be set for the cl compiler to
work.
CMake Error: your CXX compiler: "cl" was not found. Please set CMAKE_CXX_COMPILER to a valid compiler path or name.
[...snip...]
(I tried setting CMAKE_CXX_COMPILER to my Rtools gcc.exe with no luck.)
I believe that it is looking for the visual C compiler, though the docs imply that it can be done solely with the mingw or cygwin compiler environments.
Either:
Is there a problem with compiling the armadillo library and subsequent Rcpp code with different versions of the compiler? (Rtools-3.1 has gcc version 4.6.3, MinGW has gcc version 4.8.1.)
Is there a clean method for compiling armadillo with just the Rtools collection?
(Win7 x64, R-3.1.0, cygwin gcc 4.8.2, rtools 3.1 with gcc 4.6.3.)
RcppArmadillo ships its own copy of Armadillo to avoid exactly this problem. As RcppArmadillpo is used from R, it can rely on R (and R's configuration) to get LAPACK, BLAS, etc pp. We don't need to run configure to use Armadillo from R, and so we don't do.
RcppArmadillo installs the usual R CMD INSTALL ... way; this is tested before every release and has worked reliably.
As you say "your ultimate goal is to use Rcpp and RcppArmadillo", you are in fact done at the R CMD INSTALL .... You can replicate the step from source, and test the package -- all that should "just work".
The other thing to keep in mind is what the "Writing R Extensions" and "R Installation and Administration" manuals have to say about your compiler. As far is R is concerned, your g++ 4.8.* does not exist. Only the Rtools version matters, or you get into non-standard land real quick.
Related
I am trying to set up the Template Model Builder (TMB) package in R on my new M1 Mac. I have installed the silicon version of R and followed and installed TMB from CRAN. However, after I have compiled A C++ template function with compile("file.cpp"), I get the following error when I run dyn.load(dynlib("file")): (mach-o file, but is an incompatible architecture (have 'x86_64', need 'arm64e')).
I have tried to follow the tips from here, in the hopes that this would change the compilation architecture. Does anyone know how to resolve this error, or has anyone been able to set up and use TMB on an M1 Mac?
This error message suggests that the compiled C++ template function is built for the x86_64 architecture, which is not compatible with the arm64e architecture used by the M1 Mac.
To resolve this issue, you need to compile the C++ template function specifically for the arm64e architecture. Here are the steps to compile the C++ template function for the arm64e architecture on your M1 Mac:
Make sure you have the required tools installed: You will need to have Xcode installed on your M1 Mac, as well as the Command Line Tools for Xcode. You can install the Command Line Tools by running the following command in the terminal:
xcode-select --install
Set the required environment variables: You will need to set the following environment variables to ensure that the correct compilers and libraries are used for arm64e architecture:
export PATH="/Library/Developer/CommandLineTools/usr/bin:$PATH"
export CC=clang
export CXX=clang++
Compile the C++ template function: Now that you have set the required environment variables, you can compile the C++ template function using the following command:
R CMD SHLIB file.cpp -arch arm64e
This should produce a shared library file (.so) for the arm64e architecture. You can then load this library file using dyn.load(dynlib("file")) in R. I hope this helps resolve your issue with setting up TMB on your M1 Mac. If you continue to have trouble, you may want to consider reaching out to the TMB community for further assistance.
I have installed R on Windows, which creates a file C:\programs\R\R-3.5.2\modules\x64\lapack.dll . The Fortran compiler used to build R is gfortran. How can I call Lapack routines from gfortran? I tried
gfortran C:\programs\R\R-3.5.2\modules\x64\lapack.dll xlin.f
where xlin.f is the driver and get the error message
C:...\ccwsB76i.o:xlin.f:(.text+0x120): undefined reference to `sgesv_'
You can always check using the gendef program (available as part of MinGW-w64 installations) what functions/subroutines a DLL contains. Apparently "modules\x64\lapack.dll" in the installation of R for Windows is not the library that you want. The correct one is "bin\x64\Rlapack.dll"!
But this is not the end of the story. At least in case of installation of R 3.6.1, that library contains only double precision variants of the LAPACK routines. So, I needed to transform your program to use REAL*8 and DGESV. But then this worked:
> set "PATH=C:\Program Files\R\R-3.6.1\bin\x64;%PATH%"
> set "PATH=C:\msys64\mingw64\bin;%PATH%"
> gfortran xlin.f "C:\Program Files\R\R-3.6.1\bin\x64\Rlapack.dll"
> a.exe
1.0000000597179521
1.0000000618499254
1.0000000465843075
which I was able to reproduce in Linux with the default LAPACK library.
I'm using Travis CI to test my package on Linux and Mac. One of the packages in the Suggests: needs openMP. Installing this package on Travis-Linux works fine but not on Travis-Mac.
See the error.
I've tried to use
compiler:
- gcc
in my .travis.yml file, but it didn't solved this issue.
Any idea?
Edit:
Based on #Jaap's comment, I tried to use
before_install:
- if [ "${TRAVIS_OS_NAME}" == "osx" ]; then brew install llvm; fi
in my .travis.yml file, but it didn't solve the problem.
The Travis mac environment incorrectly states that it supports OpenMP, by setting SHLIB_OPENMP_CFLAGS and SHLIB_OPENMP_CXXFLAGS. OpenMP on mac is generally a disaster. You could try un-setting these environment variables (I've never tried this), or use a configure script. There is a m4 macro in the R sources which detects openmp, which you can re-use with appropriate attribution to the R Core Team. I do this in my package icd.
When submitting a package to CRAN, how can one get the resulting binaries for Windows and Mac OSX to take advantage of OpenMP?
i.e., what make or compiler hooks do the CRAN machines look for to build for OpenMP code?
Unix source
R has good OpenMP support under unix. Just include the ifdef _OPENMP. (users must download package source and compile packages on their machine).
OS X binaries
Since mid-2018, R for OS X is compiled using clang, with a custom clang giving OpenMP support. Binary packages which take advantage of OpenMP (e.g. OpenMx) run in parallel. Source compilation is eased by the compiler installer provided at CRAN toolshttps://cran.r-project.org/bin/macosx/tools/clang-6.0.0.pkg
Using other non-CRAN compilers (e.g. homebrew) is strongly advised against.
Windows binaries
As of 2019, the windows toolchain supports OpenMP and pthreads, but it's slow and not enabled by default. Comments indicate this might change.
Refs
https://cran.r-project.org/doc/manuals/R-exts.html#OpenMP-support
As of R 3.5.3 manual:
Apple builds of clang on macOS currently have no OpenMP support, but
CRAN binary packages are built with a clang-based toolchain which
supports OpenMP.
http://www.openmp.org/resources/openmp-compilers-tools gives some idea
of what compilers support what versions.
Source-based installs of CRAN packages for most MacOS users will fail and/or not have openmp, unless they have installed, e.g. via homebrew, clang with openmp support. The method for doing evolves, so search for recent posts with terms like "homebrew clang openmp makevars R CRAN".
I made a simple fortran routine
subroutine add(x,y)
real(8) :: x,y
y = x + 3
end subroutine
saved as test.f90.
I compile with
gfortran -shared test.f90 -o test.so
In R (in the same directory), I use
dyn.load('test.so')
but it gives me this error:
Error in dyn.load("test.so") :
unable to load shared object '/Users/Steven/Documents/PhD/npsR/test.so':
dlopen(/Users/Steven/Documents/PhD/npsR/test.so, 6): Symbol not found: ___addtf3
Referenced from: /usr/local/gfortran/lib/libquadmath.0.dylib
Expected in: /Library/Frameworks/R.framework/Resources/lib/libgcc_s.1.dylib
in /usr/local/gfortran/lib/libquadmath.0.dylib
Does anyone know why? I'm using mac osx Lion, with R v2.15.0 and gfortran 4.6.2.
Thank you!
Unless you really understand what you're doing, you should use gfortran that comes with R tools. The missing symbol in libgcc isn't surprising since you're trying to run code compiled with a 4.6 gfortran in a 4.2 runtime environment.
You can only use the gfortran version that was used to build R.
Since you are on Lion and presumably have Xcode installed you can get the appropriate version of gfortran from here: http://r.research.att.com/tools/
Go to section: "Apple Xcode gcc-42 add-ons" and choose the appropriate version.
You'll have to get rid of your gfortran 4.6.2 completely or make it inaccessible by changing PATH if possible (which I doubt unless it is in /opt/...).
And do use R CMD SHLIB since that will pass the correct options to compiler and linker.