On Dec 23, 2008, at 11:29 AM, Thomas Baier wrote:
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?
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
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 ;)).
Cheers,
Simon
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
