[Rd] seek() and gzfile() on 32-bit R2.12.0 in linux

[Matt Shotwell]

On Thu, 2010-06-24 at 03:48 -0400, Martin Maechler wrote: 
> >>>>> "BW" == Brandon Whitcher <bwhitcher at gmail.com>
> >>>>>     on Wed, 23 Jun 2010 12:14:35 +0100 writes:
> 
>     BW> Peter, thanks for your comments.  The reason I have taken this issue
>     BW> to R-devel is from the advice of Kurt Hornik.  An update to my package
>     BW> oro.nifti is being refused by CRAN because it fails on the
>     BW> _development_ version of R on 32-bit linux.  As we have just discussed
>     BW> (and thanks to Matt's input), the problem is not with my package but
>     BW> with the development version of R.  Hence, I wanted to alert to the R
>     BW> Core Development Team that the _unstable_ version of R appears to have
>     BW> a problem.
> 
>     BW> Obviously, I would prefer to have my new version of oro.nifti accepted
>     BW> by CRAN... but at the moment I am in between a rock and a hard place.
>     BW> I agree that the 2.12.0 release of R is quite far in the future.  Is
>     BW> there a possibility of relaxing the exclusion criteria
>     BW> for CRAN?
> 
> Well, the criteria are very  good as a general rule,
> but in the case where a new/changed package reveals a *bug* in
> R-devel (only), the package of course should still be released
> to CRAN.
> So the only remaining problem for you ;-)
> is to convince the CRAN maintainers that indeed this is a bug in
> R-devel, or probably in  zlib 1.2.4 (R 2.11.x uses zlib 1.2.3).

Indeed, according to the zlib website, there were significant changes to
the gzip internals in version 1.2.4. In fact, they have already fixed a
"big fat stinking bug in gzseek()", and recommend immediate upgrade to
version 1.2.5. I compiled zlib version 1.2.5 into R, but Brandon's bug
persists.

However, I believe this may not be a code bug, but a configuration bug
related to Large File Support and cross-compiling from 64 to 32 bits.
The zlib made changes to their LFS support in the 1.2.4 series. When I
cross-compile R-devel using a custom configuration (adding
-D_LARGEFILE64_SOURCE -m32 to compiler flags), Brandon's code appears to
work correctly. I have more details, and would be happy to discuss this
with whoever maintains the 64/32 bit R-devel build for CRAN.

> 
> Within R-core, Brian Ripley has been the zlib "principal
> investigator", and I'd wait a bit for his comment on this issue.
> 
> Martin Maechler, ETH Zurich and R-Core Team
> 
>     BW> cheers...
>     BW> Brandon
> 
>       PD> Please notice that there is NO release of R 2.12.0 until some time
>       PD> around October. You are using a build from the UNSTABLE development
>       PD> branch. The stable branch is 2.11.1 with a release date of May 31. If
>       PD> Ubuntu is claiming that there is such a thing as a R 2.12.0 release, I'd
>       PD> say that they  have a problem.
> 
>       PD> Not that we don't welcome reports on problems in the development branch,
>       PD> but do notice that it is by definition UNSTABLE, and that bugs can come
>       PD> and go without notice.
> 
>       PD> -pd
> 
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
-- 
Matthew S. Shotwell
Graduate Student
Division of Biostatistics and Epidemiology
Medical University of South Carolina
http://biostatmatt.com