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
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
