Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upDisable OpenMP on macOS + Vignette Fix #168
Conversation
| @@ -19,11 +19,11 @@ inlineCxxPlugin <- function(...) { | |||
| plugin <- | |||
| Rcpp::Rcpp.plugin.maker( | |||
| include.before = "#include <RcppArmadillo.h>", | |||
| libs = "$(SHLIB_OPENMP_CFLAGS) $(LAPACK_LIBS) $(BLAS_LIBS) $(FLIBS)", | |||
| libs = "@HAVE_OPENMP_R_CFLAG@ $(LAPACK_LIBS) $(BLAS_LIBS) $(FLIBS)", | |||
kevinushey
Aug 27, 2017
•
Contributor
Making this a package configure-time check doesn't feel right to me, IMHO. This implies that a package built on CRAN might detect OpenMP support, and that assumption will remain in place when the Rcpp binary is later served to the user. However, that assumption will fail if the user has not installed the CRAN LLVM toolchain.
I would prefer that we just checked this at runtime, rather than configure time.
Making this a package configure-time check doesn't feel right to me, IMHO. This implies that a package built on CRAN might detect OpenMP support, and that assumption will remain in place when the Rcpp binary is later served to the user. However, that assumption will fail if the user has not installed the CRAN LLVM toolchain.
I would prefer that we just checked this at runtime, rather than configure time.
eddelbuettel
Aug 27, 2017
Member
Yes, but how do you suggest we go about it?
I started down the road of 'grep'ing CXXFLAGS and looking for -fopenmp. As you know that fails on macOS.
Yes, but how do you suggest we go about it?
I started down the road of 'grep'ing CXXFLAGS and looking for -fopenmp. As you know that fails on macOS.
coatless
Aug 27, 2017
Author
Contributor
No matter what, we do need a compile time check to set the src/Makevars appropriately. This was evident with the clang-sans-openmp check Ripley is running. Regarding the build check, I do agree that would be beneficial; however, there really isn't a good way to detect OpenMP on macOS reliably as support for OpenMP is not listed within capabilities().
My only thought to that line of detection is the possibility of checking for the directory existence of /usr/local/clang4 on macOS. Other platforms have a tendency to respect setting -- or unsetting -- SHLIB_OPENMP_* where appropriate.
No matter what, we do need a compile time check to set the src/Makevars appropriately. This was evident with the clang-sans-openmp check Ripley is running. Regarding the build check, I do agree that would be beneficial; however, there really isn't a good way to detect OpenMP on macOS reliably as support for OpenMP is not listed within capabilities().
My only thought to that line of detection is the possibility of checking for the directory existence of /usr/local/clang4 on macOS. Other platforms have a tendency to respect setting -- or unsetting -- SHLIB_OPENMP_* where appropriate.
| @@ -13,7 +13,7 @@ before_install: | |||
| - ./run.sh bootstrap | |||
|
|
|||
| install: | |||
| - ./run.sh install_aptget r-cran-rcpp r-cran-runit r-cran-matrix r-cran-pkgkitten r-cran-jsonlite python-scipy | |||
| - ./run.sh install_aptget r-cran-rcpp r-cran-runit r-cran-matrix r-cran-pkgkitten r-cran-jsonlite python-scipy r-cran-highlight | |||
eddelbuettel
Aug 27, 2017
Member
This comingles unrelated issues.
All Suggests are skipped by default. This worked (for me) for years.
This comingles unrelated issues.
All Suggests are skipped by default. This worked (for me) for years.
eddelbuettel
Aug 27, 2017
Member
Ah, wait, maybe this is different as we didn't use highlight before -- because we also forgot it as vignette engine.
Ah, wait, maybe this is different as we didn't use highlight before -- because we also forgot it as vignette engine.
| @@ -23,6 +23,6 @@ License: GPL (>= 2) | |||
| LazyLoad: yes | |||
| LinkingTo: Rcpp | |||
| Imports: Rcpp (>= 0.11.0), stats, utils, methods | |||
| Suggests: RUnit, Matrix, pkgKitten, reticulate | |||
| Suggests: RUnit, Matrix, pkgKitten, reticulate, highlight | |||
eddelbuettel
Aug 27, 2017
Member
That is you deciding you need to throw this in.
As I said yesterday, it does not throw a warning or note for me when checking, nor did CRAN comment on it. As such it is not clearly needed.
It surely does not belong into a hotfix-PR about OpenMP.
That is you deciding you need to throw this in.
As I said yesterday, it does not throw a warning or note for me when checking, nor did CRAN comment on it. As such it is not clearly needed.
It surely does not belong into a hotfix-PR about OpenMP.
coatless
Aug 27, 2017
•
Author
Contributor
This is to address the build error happening on Ripley's machine. When we discussed this, the conclusion was to add it alongside of the OpenMP fix to save a PR.
I guess the slogan should be:
No PR shalt be spared!
😆
This is to address the build error happening on Ripley's machine. When we discussed this, the conclusion was to add it alongside of the OpenMP fix to save a PR.
I guess the slogan should be:
No PR shalt be spared!
eddelbuettel
Aug 27, 2017
Member
I doubt that. When we talked about the BDR failure we concluded it was a segfault neither one of us understood or was able to replicate.
In any event, the two commits were right and good, and I took it as opportunity to learn some more magit and cherry-picked them into a distinct PR which by now is in master. So the vignette issue is taken care of.
Leaves
- the macOS clusterfuck, and the valid point by @kevinushey
- the unexplicable fail on clang-on-fedora which I plan to simply ignore unless someone shows how to replicate
I doubt that. When we talked about the BDR failure we concluded it was a segfault neither one of us understood or was able to replicate.
In any event, the two commits were right and good, and I took it as opportunity to learn some more magit and cherry-picked them into a distinct PR which by now is in master. So the vignette issue is taken care of.
Leaves
- the macOS clusterfuck, and the valid point by @kevinushey
- the unexplicable fail on clang-on-fedora which I plan to simply ignore unless someone shows how to replicate
|
Re: detecting OpenMP support at runtime, I think we could just try (on macOS only, probably) calling
If that fails, we could detect whether OpenMP is the culprit based on the compiler output:
And then override the necessary environment variables, e.g. by unsetting these environment variables (and possibly others)
Alternatively, we just document this behavior for macOS users and say "sorry, here's how you can work around it". |
|
In essence, the true configure tests for OpenMP do just that. We could be super-clever, launch an environment on package startup and tests once per session (on Darwin / macOS) and then re-use that in inline.R. That would bring that part back to run-time. But we do need a compile-time / installation time switch as well. Or, simpler still, we just Eff It and turn OpenMP off on macOS (and document for the four motivated and capable users how to locally override). |
|
But all this is just so ... fragile. So my preference (right now) is to just turn it off. Sorry, macOS. |
|
I'm fine with just turning it off. Enterprising users can do the work to re-enable it and install the custom LLVM toolchain if they so desire. |
|
At this stage, I'm more of a fan of just disabling OpenMP on macOS. The alternative options:
would be either add additional (read: unnecessary) delay to compiling or impact the load time of the package for macOS users. Needless to say, it would also introduce a new point of failure. Furthermore, due to the procedure of Having said this, the implication of the // [[Rcpp::plugins(openmp)]]So, really the best solution is just to ship a disabled copy for macOS until the toolchain is appropriately detectable. |
|
It think that is the right approach. I just carried the first half of your tests over in a (much simpler) version. The core chunk now reads: ## Check for broken systems produced by a corporation based in Cupertino
AC_MSG_CHECKING([for macOS])
RSysinfoName=$("${R_HOME}/bin/Rscript" --vanilla -e 'cat(Sys.info()[["sysname"]])')
if test x"${RSysinfoName}" == x"Darwin"; then
AC_MSG_RESULT([found])
AC_MSG_WARN([OpenMP unavailable and turned off.])
have_openmp="#define ARMA_DONT_USE_OPENMP 1"
else
AC_MSG_RESULT([not found as on ${RSysinfoName}])
## Check for OpenMP
AC_MSG_CHECKING([for OpenMP])
## if R has -fopenmp we should be good
allldflags=$(${R_HOME}/bin/R CMD config --ldflags)
hasOpenMP=$(echo ${allldflags} | grep -- -fopenmp)
if test x"${hasOpenMP}" == x""; then
AC_MSG_RESULT([missing])
have_openmp="#define ARMA_DONT_USE_OPENMP 1"
else
AC_MSG_RESULT([found])
have_openmp="#define ARMA_USE_OPENMP 1"
fi
fiI still need to put in the change you worked out to 'blank' the use of In Hopefully that'll do. |
|
With apologies to @coatless for trampling over / ignoring this PR (off which I cherry-picked two commits though) I have a new branch that does the castration of OpenMP under macOS. Can you fancy people with macOS machines give it a spin? It is here and it "works for me" but then I don't have the exqusite machinery it is aiming at. No hurry, we've been at this long enough. |
|
Works! Killing this. Please PR the other.
|
|
What about
|
No description provided.