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.
Related
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.
I just downloaded the latest release of ArrayFire (3.3.1), and am trying to build it. I'm stuck at cmake . though. I installed a bunch of missing libraries, reran it, and now I get:
-- Could NOT find LAPACK (missing: LAPACK_LIBRARIES)
CMake Warning at src/backend/opencl/CMakeLists.txt:38 (MESSAGE):
LAPACK not found. Functionality will be disabled
and
CMake Error: The following variables are used in this project, but they are set to NOTFOUND.
Please set them or make sure they are set and tested correctly in the CMake files:
GLEWmxd_LIBRARY
linked by target "afcpu" in directory /home/joeuser/src/arrayfire-full-3.3.1/src/backend/cpu
linked by target "afcuda" in directory /home/joeuser/src/arrayfire-full-3.3.1/src/backend/cuda
linked by target "afopencl" in directory /home/joeuser/src/arrayfire-full-3.3.1/src/backend/opencl
I have installed lapack, and it's at /usr/lib/liblapack.so (that's an alternatives symlink, but it's not broken). Also installed lapacke.
ArrayFire requires the LAPACKE library (On Ubuntu, liblapacke-dev, and the graphics part requires GLEW-MX (on Ubuntu, libglewmx-dev).
I want to compile PhantomJS with gstreamer. I downloaded the source code and started the build process with
./build.sh --qmake-args WEBKIT_CONFIG+='use_gstreamer'
I get the following Error
Project ERROR: gstreamer-1.0 development package not found
I have an debian 8.0 system with installed libgstreamer1.0 and glib2.0 (installed with apt-get).
Can someone help me?
If you haven't installed them, you'll need the development packages as well which should be something like libgstreamer(X.X.X)-dev, where X.X.X is whichever version of gstreamer you have installed. The development package has the necessary header files required for compilation.
you may need to modify the build script to add "{GStreamerInstallDir}/1.0/{architecture}/lib/pkgconfig" to the CMAKE_MODULE_PATH configuration so cmake can find the package.
Not sure how to do this in your environment as I build on a windows OS where I just specify this using an environment variable from a wrapping batch script.
I am working on an R package containing Fortran source files. The structure of the Fortran code is rather complex, with many dependencies, therefore I have a Makefile in the src folder for the compilation of the shared library.
So far I have been compiling this package on my machine running Ubuntu 14.04, without any problems. I am now trying to compile it on Windows using Rtools, and I am running into a problem when linking the objects to produce the shared library. More precisely, the linker does not find the functions REXIT, RWARN and RCHKUSR, as I get the following error messages:
undefined reference to `rchkusr_'
undefined reference to `rexit_'
undefined reference to `rwarn_'
These functions are supposed to be in the shared library R.dll (libR.so under Linux). I checked this library with Dependencies Walker and I could find these functions. I have tried to link with -I C:/Program\ Files/R/R-3.1.1/bin/i386/R.dll to make explicit the reference to the shared library. I have tried to recompile with -fno-underscoring to make sure the underscores were not the problem. Nothing helped.
Any ideas where the problem could come from? Any suggestions would be more than welcome!
Under Linux I did not have to do anything special, the linker found the functions without specifying anything in the Makefile.
I am using R version 3.1.1 and Rtools version 3.1.
Many thanks for your help.
After fiddling with the Makefile, I finally found the solution to my problem: The flags I was trying to pass to the linker were wrong. Only the path of the shared library R.dll should be specified, using -L, and the name of the library should be specified using the flag -lR at the end of the command. In short, I specified
gfortran -shared *.o -o myLib.dll -L C:/Program\ Files/R/R-3.1.1/bin/i386 -lR
to create myLib.dll and it worked! I guess I got confused because under Linux there is no need to specify anything, the linker finds the shared library on its own.
Probably not the best and most portable solution I can get (I now have two Makefiles to deal with, Makefile for Linux and Makefile.win for Windows...), but good enough for now.
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.