11

I have an R package which is easily sped up by using OpenMP. If your compiler supports it then you get the win, if it doesn't then the pragmas are ignored and you get one core.

My problem is how to get the package build system to use the right compiler options and libraries. Currently I have:

PKG_CPPFLAGS=-fopenmp
PKG_LIBS=-fopenmp

hardcoded into src/Makevars on my machine, and this builds it with OpenMP support. But it produces a warning about non-standard compiler flags on check, and will probably fail hard on a machine with no openMP capabilities.

The solution seems to be to use configure and autoconf. There's some information around here:

http://cran.r-project.org/doc/manuals/R-exts.html#Using-Makevars

including a complex example to compile in odbc functionality. But I can't see how to begin tweaking that to check for openmp and libgomp.

None of the R packages I've looked at that talk about using openMP seem to have this set up either.

So does anyone have a walkthrough for setting up an R package with OpenMP?

[EDIT]

I may have cracked this now. I have a configure.ac script and a Makevars.in with @FOO@ substitutions for the compiler options. But now I'm not sure of the workflow. Is it:

  • Run "autoconf configure.in > configure; chmod 755 configure" if I change the configure.in file.
  • Do a package build.
  • On package install, the system runs ./configure for me and creates Makevars from Makevars.in

But just to be clear, "autoconf configure.in > configure" doesn't run on package install - its purely a developer process to create the configure script that is distributed - amirite?

Spacedman
  • 92,590
  • 12
  • 140
  • 224

2 Answers2

3

Methinks you have the library option wrong, please try

## -- compiling for OpenMP 
PKG_CXXFLAGS=-fopenmp
##
## -- linking for OpenMP
PKG_LIBS= -fopenmp -lgomp

In other words, -lgomp gets you the OpenMP library linked. And I presume you know that this library is not part of the popular Rtools kit for Windows. On a modern Linux you should be fine.

In an unrelease testpackage I have here I also add the following to PKG_LIBS, but that is mostly due to my use of Rcpp:

$(shell $(R_HOME)/bin/Rscript -e "Rcpp:::LdFlags()") \
                              $(LAPACK_LIBS) $(BLAS_LIBS) $(FLIBS)

Lastly, I think the autoconf business is not really needed unless you feel you need to test for OpenMP via configure.

Edit: SpacedMan is correct. Per the beginning of the libgomp-4.4 manual:

1 Enabling OpenMP

To activate the OpenMP extensions for C/C++ and Fortran, the compile-time flag `-fopenmp' must be specified. This enables the OpenMP directive [...] The flag also arranges for automatic linking of the OpenMP runtime library.

So I stand corrected. Seems that it doesn't hurt to manually add what would get added anyway, just for clarity...

Dirk Eddelbuettel
  • 360,940
  • 56
  • 644
  • 725
  • Hmm no, just sticking -fopenmp in the compile and link steps gives me an executable linked with libgomp, I don't need to specify it explicitly... I'm pretty sure, but I'll check again in the morning. – Spacedman Feb 15 '11 at 23:09
  • Be great to update this for R 3.4.1 which uses the clang build chain – tim Sep 07 '17 at 18:10
  • Sure but this is a _six-year old answer_ and the underlying technology changes every year. Your best _updated_ bet may be the R Installation and Administration manual. – Dirk Eddelbuettel Sep 07 '17 at 19:33
1

Just addressing your question regarding the usage of autoconf--no, you do not want to run autoconf with any arguments, nor should you redirect its output. You are correct that running autoconf to build the configure script is something that the package maintainer does, and the resulting configure script is distributed. Normally, to generate the configure script from configure.ac (older packages use the name configure.in, but that name has been discouraged for several years), the developer simply runs autoconf with no arguments. Before running autoconf, it is necessary to run aclocal, autoheader, libtoolize, etc... There is also a tool (autoreconf) which simplifies the process and invokes all the required programs in the correct order. It is now more typical to run autoreconf instead of autoconf.

William Pursell
  • 204,365
  • 48
  • 270
  • 300