I am about to go running so I just scanned this for now. See below. On 20 January 2011 at 18:03, [email protected] 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. | | 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 | 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. Dirk | 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 | [email protected] | https://stat.ethz.ch/mailman/listinfo/r-sig-debian -- Dirk Eddelbuettel | [email protected] | http://dirk.eddelbuettel.com _______________________________________________ R-SIG-Debian mailing list [email protected] https://stat.ethz.ch/mailman/listinfo/r-sig-debian
