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.
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.
When I try to compile R packages from source, it uses the compilers and settings defined in etc/Makeconf within the R installation directory. How can I override these settings?
I have an ~/.R/Makevars file (suggested e.g. here), and I included the settings I want there, but these are not being used for some reason. Why not, and how can I fix this?
I could not find the official documentation on ~/.R/Makevars and Makeconf—links would be welcome.
In the past, this very same setup used to work correctly for me, but recently it doesn't. I assume something must have changed in recent R versions, but I am not sure when. Were there any recent changes that could have affected this?
Motivation and context:
I am on macOS and I want to use gfortran from MacPorts. Thus I set FC = /opt/local/bin/gfortran-mp-11 and FLIBS = -L/opt/local/lib/gcc11 -lgfortran -lquadmath -lm in ~/.R/Makevars. However, the system still wants to use a gfortran installation in /usr/local, which does not exist on my machine. It clearly takes the paths and options from etc/Makeconf. I am using the official R binaries.
It turns out that the reason why ~/.R/Makevars was ignored on my machine when trying to build a certain package was a bug in withr:
https://github.com/r-lib/withr/issues/169
Installing the development version of withr using devtools::install_github("r-lib/withr#master") fixed the problem.
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 =
Does anyone have a link to clear instructions on how to install and configure the necessary latex packages to build R packages on a mac?
I have some scripts for building and checking R packages on a mac server. They seemed to work fine, but after upgrading to R 3.1.3, many of the packages started failing with
Error in texi2dvi(file = file, pdf = TRUE, clean = clean, quiet = quiet, :
Running 'texi2dvi' on 'networkVignette.tex' failed.
Messages:
sh: /usr/local/bin/texi2dvi: No such file or directory
Calls: <Anonymous> -> texi2pdf -> texi2dvi
Execution halted
I found a thread which seemed to suggest I need a more recent version texinfo (5.2) than what is installed by default. And apparently I've I've got the wrong version installed in the wrong location?
which texi2pdf
/sw/bin/texi2pdf
texi2pdf --version
texi2pdf (GNU Texinfo 5.1) 5234
(same version is reported when running system('texi2pdf --version') in R )
This thread gives a link to a texinfo 5.2 source collection:
http://r.789695.n4.nabble.com/R-CMD-build-looking-for-texi2dvi-in-the-wrong-place-R-devel-td4701706.html
But I'm not familiar with installing executable from a tar.gz file on a mac. The R mac help pages I found suggest installing MacTex, which I tried but that didn't seem to help.
** Update: ** additional discussion of related problems on R-SIG-mac mailing list:
https://groups.google.com/forum/#!topic/r-sig-mac/xjyuFdl5Ezk
Update:
Here is where I'm currently at:
I removed my /sw directory to uninstall fink and all of its packages (couldn't figure out how to upgrade it)
installed homebrew
brew install texinfo installs version 5.2 the package,
but generates the message This formula is keg-only, which means it was not symlinked into /usr/local and actually installs in in /usr/local/Cellar/texinfo/5.2/bin which means it is not on the path and R won't find it.
manually symlink each of the texi2pdf, texi2dvi , etc as vincent suggests (this is because R has the /usr/local/bin location as default in the tools::texi2dvi function?
edited the /etc/paths file on the system to add /usr/local/bin so that finds the brew installed 5.2 version before it finds it before the osx system supplied version 4.6 version. This may not be necessary because R has it hardcoded?
All of this gets rid of the "can't find texi* errors", and gives me a bunch of latex errors (which I don't see on unix and windows builds) so I'm still kind of stuck.
This seems very hackish, so there must be a cleaner way? But it sounds like stuff with tex and mac is very sketchy at the moment? https://tex.stackexchange.com/questions/208181/why-did-my-tex-related-gui-program-stop-working-in-mac-os-x-yosemite
This worked for me on Mavericks and on Yosemite:
ln -s /usr/bin/texi2dvi /usr/local/bin/texi2dvi
ln -s /usr/bin/texi2pdf /usr/local/bin/texi2pdf
On my Lion system both the command which texi2pdf at a Terminal/bash prompt and from a R.app GUI prompt tell me that I have that program in:
system("which texi2pdf")
#/opt/local/bin/texi2pdf
That is a location typical for MacPorts installation. I think the /usr/local/bin/ is what the binary R version "expects". I'm not really that UNIX savvy, but I think the you can modify the PATH environment variable so that R will be able to find your installation. (Whether it will be compatible I cannot say since so much detail is missing from your question.) My Tex installation is MacTex, which I got from https://www.tug.org/mactex/. I admit to having a cobbled-together system:
system("echo $PATH")
# /opt/local/bin:/opt/local/sbin:/sw/bin:/sw/sbin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/texbin:/usr/X11/bin:/usr/X11R6/bin
That gets set at the beginning of an R session because this is the first line in my .Rprofile-(invisible)file:
Sys.setenv(PATH="/opt/local/bin:/opt/local/sbin:/sw/bin:/sw/sbin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/texbin:/usr/X11/bin:/usr/X11R6/bin")
I think /sw/bin/ installations signify a fink install, which I have had very little success with. Simon Urbanek suggests not using any package installers, but then leaves the rest of us UNIX weenies very little in the way of worked examples of how to install that various external packages that underpin the many interesting and oh-so-useful R packages. So I feel your pain, but I'm not running for President.
So I suppose you could try this at your R console before again attempting one of the earlier unsuccessful installs:
Sys.setenv(PATH=paste( Sys.getenv()$PATH, # should be the character string of the $PATH
"/sw/bin/", sep=":")
)
Wish I could offer guarantees, but if it breaks the only guarantee is that you get to keep all the pieces.
I ran into a similar error message using Mavericks 10.9.5 (factory configured) and R 3.1.
It turns out that I didn't have pdfLaTex. I went to this page: http://tug.org/mactex/ and downloaded the MacTex installation package. It's big (>2GB) but after I installed it, my R package build problems went away.
Hope this might be helpful to anyone else who runs into this error message.
All: Apologies in advance for what I hope is an easy question. It's been many years since I've worked in a Unix(-like) environment...
I'm trying to install RApache on a web server running the RHEL5 64-bit OS. I've successfully installed Apache and confirmed it works. I've also successfully installed R (R-2.13.0) with shared library. I've confirmed that libBlas.so and libR.so are installed; location: /R/R-2.13.0/lib
However, when I try to configure RApache ( sudo ./configure --with-apache2-apxs=/usr/local/apache2/bin/ --with-R=/R/R-2.13.0/) I get the following error:
R was not built as a shared
library Either build it with one,
or use another install of R
configure: error: aborting!
I've reinstalled R twice now and have confirmed in libtool that it says:
# Whether or not to build shared
libraries. build_libtool_libs=yes
Finally, I've searched high and low for some path or flag I need to set without success. Any help would be greatly appreciated.
Thanks,
Ron
You need to compile R with the appropriate flags. At the configure stage you need to include --enable-R-shlib so that R is built as a shared library.
You may need to further consult appendix B1 of http://cran.r-project.org/doc/manuals/R-admin.pdf which describes further issues.