From simon.urbanek at r-project.org  Tue Dec 23 22:45:59 2008
From: simon.urbanek at r-project.org (Simon Urbanek)
Date: Tue, 23 Dec 2008 16:45:59 -0500
Subject: [Rd] rscproxy version conflict
In-Reply-To: <405593F1A35DDD11B2B4000C29F5CF53034642@exchange-server.ow.ks>
References: <405593F1A35DDD11B2B4000C29F5CF53034642@exchange-server.ow.ks>
Message-ID: <B291D293-23F7-4095-95EF-3C48525EB603@r-project.org>


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



[Rd] rscproxy version conflict
Simon Urbanek