After installing the package 'rscproxy' downloaded from the CRAN server, I get the following error message from R 2.8.0 about a version conflict : package 'rscproxy' successfully unpacked and MD5 sums checked The downloaded packages are in C:\Documents and Settings\John Meerman\Local Settings\Temp\RtmpbK9mxN\downloaded_packages updating HTML package descriptions> local({pkg <- select.list(sort(.packages(all.available = TRUE)))+ if(nchar(pkg)) library(pkg, character.only=TRUE)}) *Warning message: package 'rscproxy' was built under R version 2.8.1 *> This prevents me e.g. to use the R (D)COM 3.0 server. John Meerman [[alternative HTML version deleted]]
On Thu, 18 Dec 2008, meerman wrote:> After installing the package 'rscproxy' downloaded from the CRAN server, I > get the following error message from R 2.8.0 about a version conflict :I see no 'error message' nor no 'confict'. I see a *warning* which you could stop by using 2.8.1 RC or by updating to 2.8.1 early next week, but should be harmless.> > > > > > package 'rscproxy' successfully unpacked and MD5 sums checked > > > > The downloaded packages are in > > C:\Documents and Settings\John Meerman\Local > > Settings\Temp\RtmpbK9mxN\downloaded_packages > > updating HTML package descriptions > >> local({pkg <- select.list(sort(.packages(all.available = TRUE))) > > + if(nchar(pkg)) library(pkg, character.only=TRUE)}) > > *Warning message: > > package 'rscproxy' was built under R version 2.8.1 *> > > > > This prevents me e.g. to use the R (D)COM 3.0 server. > > > > > > > > > > John Meerman > > > > > [[alternative HTML version deleted]] > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel >-- Brian D. Ripley, ripley at stats.ox.ac.uk Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UK Fax: +44 1865 272595
We found out about this problem only a few days ago. The reason is that the official binary packages were compiled with 2.8.1, but the distributed Windows binary of R was still 2.8.0. rscproxy needs to be compiled for the correct version of R. Now with R 2.8.1 being release officially the problem should disappear, but we (which is mostly Thomas Baier, the mastermind behind rcom and R(D)COM server) will try to find a way to avoid this problem with the next R update. Before R 2.8.0, rproxy.dll distributed with R itself was supplying the underlying mechanism for the rcom package and R(D)COM server. rproxy.dll was removed from R itself, and rscproxy is the current substitute. rproxy.dll, being part of R itself, always matched the R version to the very last digit. With rscproxy, it is more difficult to stay in sync. meerman wrote:> After installing the package 'rscproxy' downloaded from the CRAN server, I > get the following error message from R 2.8.0 about a version conflict : > > > > > > package 'rscproxy' successfully unpacked and MD5 sums checked > > > > The downloaded packages are in > > C:\Documents and Settings\John Meerman\Local > > Settings\Temp\RtmpbK9mxN\downloaded_packages > > updating HTML package descriptions > >> local({pkg <- select.list(sort(.packages(all.available = TRUE))) > > + if(nchar(pkg)) library(pkg, character.only=TRUE)}) > > *Warning message: > > package 'rscproxy' was built under R version 2.8.1 *> > > > > This prevents me e.g. to use the R (D)COM 3.0 server. > > > > > > > > > > John Meerman > > > > > [[alternative HTML version deleted]] > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > > > ------------------------------------------------------------------------ > > > No virus found in this incoming message. > Checked by AVG - http://www.avg.com > Version: 8.0.176 / Virus Database: 270.9.19/1854 - Release Date: 12/17/2008 7:21 PM >-- Erich Neuwirth, University of Vienna Faculty of Computer Science Computer Supported Didactics Working Group Visit our SunSITE at http://sunsite.univie.ac.at Phone: +43-1-4277-39464 Fax: +43-1-4277-39459
Simon Urbanek wrote:> FWIW: technically, you don't have to match the patch level version. > Although default DLL checks usually require perfect match, it should > be safe to require that R version lies in [x.y.z, x.y+1.0) where > x.y.z is the R version that the interfacing DLL was compiled against. > (And hence it is safe to use R x.y.0 as the base for compilation until > R x.y+1.0 is released).The check that has been implemented works as: snprintf(Rversion, 25, "%s.%s", R_MAJOR, R_MINOR); if(strncmp(getDLLVersion(), Rversion, 25) != 0) { ... check failed } ... check ok Quoting from http://cran.r-project.org/doc/manuals/R-exts.html int main (int argc, char **argv) { structRstart rp; Rstart Rp = &rp; char Rversion[25], *RHome; sprintf(Rversion, "%s.%s", R_MAJOR, R_MINOR); if(strcmp(getDLLVersion(), Rversion) != 0) { fprintf(stderr, "Error: R.DLL version does not match\n"); exit(1); } ... this looks very similar. According to your message, full binary compatibility is given for same R (major.minor) versions, e.g. 2.8.0 is fully compatible with 2.8.1, but may not be fully compatible with 2.9.0. Is there a "compatible DLL version" that can be queried or is using getDLLVersion() the recommended approach and ignoring everything after the second '.'? And if 2.8.0 and 2.8.1 are fully compatible, why is a warning issued, if a package built with R 2.8.1 is loaded in R 2.8.0? Thomas
Simon, first, I'd like to apologize, that my previous message has been sent to you directly. I have not checked the receivers list when clicking reply in my E-mail program. Simon Urbanek wrote:> On Jan 7, 2009, at 2:05 , Thomas Baier wrote: > >> Simon, >> >> Simon Urbanek wrote: >>>> And if 2.8.0 and 2.8.1 are fully compatible, why is a warning >>>> issued, if a package built with R 2.8.1 is loaded in R 2.8.0? >>>> >>> >>> It's ok to use a package built for 2.8.0 in 2.8.1 but not vice >>> versa. It is rare, but it has happened before that a bugfix or >>> visibility change adds a symbol in x.y.1 that was not there in >>> x.y.0. Then if your package checks for that particular feature and >>> uses it you cannot use that binary with x.y.0. Again, this is >>> rather rare and you as the >> >> so this was exactly what has occured. Users having installed R 2.8.0 >> (as >> 2.8.1 has not been released then) and installing a package from CRAN >> which has been built for 2.8.1. >> >> >>> package author know about it, but to be on the safe side I was >>> recommending against that. However, as Brian pointed out this >>> happens far more often on the R function level than on the C API >>> level. >>> >>> (I know about this DLL version check because it was the first >>> change I >>> made to JRI since I wasn't willing to release Windows binary some >>> five times a year ;)). >> >> As far as I have understood Brian's message, one should just parse >> for the second '.' in the version string and omit everything >> afterwards for comparison. >> >> What I would really like to have is some new API function to check >> compatibility. If this was there both on R user level (for R language >> constructs and functions) and on C level (for packages/applications >> relying on the C API), then this would be a fine solution for >> compatiblity without issuing any warnings about wrong versions. >> > > Semantically that's not really possible since the result would always > be FALSE. The point is that if you use something that has been fixed > or added, you may run into issues since the behavior changed. R cannot > know whether that affects you package or not. Therefore it's safer to > declare patch-level releases compatible (they don't "break" existing > binaries) and everything else incompatible (as Brian was suggesting). > However, my point was that *you* can decide to exploit changes in > patch-level updates if you desire so (a practical example here is > R_SignalHandlers which was introduced (exposed) in 2.3.1 and thus a > patch-level), but in that case it is your decision not some R > incompatibility. I hope this makes clear what I was describing > earlier. In general forward binary compatibility between patch-level > versions is guaranteed and backward if you don't use features added > later on.That's true for fixes, which will break compatibity (but are required as well). If I had used R_SignalHandlers in a package, then I would have had to restrict the package to be compatible with R >= 2.3.1, not with versions before. This should be something in the DESCRIPTION file. The only thing (but code-breaking fixes) I can imagine is a compile-time check in the package, so it behaves differently for < 2.3.1 and >= 2.3.1. Best, Thomas