[R-sig-Debian] GPU packages and 'Debian R Policy'
edd at debian.org
Sat Jan 22 15:58:42 CET 2011
On 22 January 2011 at 06:59, Dirk Eddelbuettel wrote:
| I am about to go running so I just scanned this for now. See below.
Ok, now with a chance to actually proof-read and form full sentences...
| On 20 January 2011 at 18:03, Kevin.Buckley at ecs.vuw.ac.nz wrote:
| | Hi there,
| | Moving this request for info over from an R-HPC-SIG list thread as
| | the issue is less HPC than something that has bitten me as a result
| | of trying to install HPC (read CUDA) R packages.
| | Background to this is that I have both a Ubuntu host for a Tesla card
| | that some researchers are looking to do CUDA-related R computation on,
| | and a prototype, RHEL-based, cluster that is being used to offer a
| | technology preview, for our central IT facilitator, of the interfaces
| | to the NZ national-level grid infrastructure, a cluster upon which I
| | installed R from source into /opt/R, a personal choice, so as to keep
| | away from /usr/local.
| | I've thus recently become aware that the Ubuntu R has the de-facto
| | location of /usr/local/lib/R/site-library as the place that any
| | packages not available via the package manager should go and that
| | that location is propagated into R's package build system via use
| | of the R_LIBS_SITE variable set in R_HOME/etc/Renviron.
Note that the setting or R_LIBS_SITE in R_HOME/etc/Renviron (and
/etc/R/Renvrion as a convenience symlink) is meant to be a _sensible default
value_ for most situations, not an iron-clad default. You are free to define
/org/R/library as a first value of what gets into .libPaths() via R_LIBS_SITE
Your systems, your rules. We aim to provide sensible defaults, not to dictate
Note that the first value shown by .libPaths() in R becomes the default for
install.packages() et al, which can also be overriden on each call (and
likewise for R CMD INSTALL).
| | As noted in the 'Debian R Policy' discussion I've now read, from-source
| | R installations have neither /usr/local/lib/R/site-library nor
| | R_HOME/etc/Renviron out-of-the-tarball.
| | On my built-from-source R installtion, I had gone down the route of
| | using /opt/Rlibs, to correspond with /opt/R, and then ensuring
| | that users would get R_LIBS=/opt/Rlibs set in the environment
| | that their jobs would be started in. That worked OK for Rmpi
| | so I guess I made the (a?) right choice.
| | My original query had centered around whether or not I could/should
| | replicate the 'Debian R Policy' approach, for example by simply
| | linking /opt/Rlibs back to /usr/local/lib/R/site-library or similar.
| | Not that big an issue, as things work, but a bit of consistency
| | never did much harm.
| | I've since hit another snagette though, hence me now formally
| | posting here so as to get some clarification if at all possible
| | before addressing the original issue.
| | On the Ubuntu host for the Tesla, I was trying to install the
| | cudaBayesreg package.
| | This gets its compile-time include path by doing an `R RHOME`
| | and adding "/include" to it.
| | It thus ends up trying to compile a source code file using
| | -I/usr/lib64/R/include
| | but that fails to pull in the Rmath.h include file that the
| | source file requires but doesn't find, not least because
| | there is no `R RHOME`/include.
| | I thus went looking for said Rmath.h and found one to be at:
| | /usr/share/R/include/Rmath.h
| | and so tried to get the cudaBayesreg installer to take notice
| | of that location.
| | I tried a number of approaches to coddling the underlying configure
| | without much success.
| | The small success I did have though then showed up that even
| | though I had an Rmath.h, I didn't have any Rmath libraries,
| | because, it turns out, they are in a seperate package.
| | However, on installing Ubuntu's r-mathlib package, I find that
| | it doesn't put Rmath.h in R_HOME/include but simply dumps it
| | in the system area /usr/include and uses similar system dirs
| | for the libs.
| Red herring. Rmath is for _separate non-R programs wanting to link with the
| functions in that header_ which is why that
.. file is installed in /usr/include to be immediately available to R and
Hope this helps, Dirk
| | Of course, the cudaBayesreg now compiles, but it might as well
| | not have bothered specifying -I$(R_HOME)/include, as it'll get
| | the /usr/include copy gratis.
| | So, what's going on?
| | 1) Should there be an "include" directory under $(R_HOME) or rather
| | what R reports as being its "RHOME".
| No. Years back I worked with R Core to make R itself use a different variable
| rather than cutting and pasting "$RHOME/include"
| | 2) Why is there an Rmath.h in
| | /usr/share/R/include/Rmath.h
| | even when you don't have the Rmath package.
| | 3) Why does the Rmath package put its Rmath.h in the system dir
| | and not below an "R directory"
| See above. Maybe it is
| 4) cudaBayesReg has a weak/broken install script.
| I'd treat this as a local cudaBayesReg problem. I have yet to install that
| package. The main CUDA package (gputools) works fine.
| Gotta go. More later, maybe.
| | If it's of any use, I recently upgraded, on Dirk Eddelbuettel's
| | advice, the Ubuntu's standard R packages with the 2.12 ones
| | from a $CRANmirror/bin/linux/ubuntu/
| | Any thoughts/info welcome,
| | Kevin
| | --
| | Kevin M. Buckley Room: CO327
| | School of Engineering and Phone: +64 4 463 5971
| | Computer Science
| | Victoria University of Wellington
| | New Zealand
| | _______________________________________________
| | R-SIG-Debian mailing list
| | R-SIG-Debian at r-project.org
| | https://stat.ethz.ch/mailman/listinfo/r-sig-debian
| Dirk Eddelbuettel | edd at debian.org | http://dirk.eddelbuettel.com
| R-SIG-Debian mailing list
| R-SIG-Debian at r-project.org
Dirk Eddelbuettel | edd at debian.org | http://dirk.eddelbuettel.com
More information about the R-SIG-Debian