[GRASS5] CygWIN: MinGW compilation of R/GRASS interface

[Roger Bivand]

On Thu, 13 Feb 2003, Eric G. Miller wrote:

> On Thu, Feb 13, 2003 at 10:58:10PM +0100, Roger Bivand wrote:
> 
> > Today's big disappointment is however that cell and fcell files are being
> > written wrongly. They are slightly larger than the "correct" ones. The
> > scenario is that R also uses xdr and zlib functions - on Linux the same
> > ones that GRASS finds during configure. Consequently, they (or some
> > version of them) are already "in" the R.dll that the GRASS.dll is
> > dynalycally loaded into, so all the dependencies and references are
> > satisfied. Under Linux they appear to generate the same file content as
> > CygWin GRASS - locations are mutually exchangable. My intuition is that
> > they do work cross-platform because R save objects (first xdr, then zlib)
> > do transfer from Win/MinGW to Linux, but the GRASS xdr/zlib don't - that 
> > is Cygwin GRASS programs can't read what the MinGW R/GRASS interface has 
> > written. The MinGW R/GRASS interface can't read then either, but 
> > curiously, it reads the zlib'ed, xdr'ed FCELL layers created by GRASS 
> > itself on whatever platform!
> > 
> > Because compression and XDR happen at the same places in the code for
> > writing FCELLs, I'd like to ask 1) if compression of cell and/or fcell
> > files can be turned off? 2) Beyond the #define DEBUG statements in
> > libes/gis files, does anyone have any experience of debugging XDR - if I
> > could turn off compression, I would have a chance of seeing if the problem
> > is incompatibility in zlib across platforms, in xdr across platforms, or
> > something else getting into the files (more ^M??); I would write a small
> > program just to read the fcell file to check its contents against the
> > values being written. My suspicions of a residual ^M or similar problem
> > are reinforced by CELL rasters also failing, and they don't use xdr or
> > zlib (do they?).
> 
> New floating point rasters are created/opened with creat(). There aren't
> any flag arguments, so it'd have to be changed to use open() iff
> carriage returns are the problem and the O_BINARY is needed to change
> that.  If you redirect all G_open_fp_cell_new() to
> G_open_fp_cell_new_uncompressed()  in opencell.c, then all new FP
> rasters should be created as "uncompressed".  The default is pretty much
> hardwired to use compression.
> 
> I suspect neither XDR nor ZLIB are at fault...

So did I, but there were too many "things" going on there. Eric's
intuition was quite right - setting the fd and null_fd in opencell.c to
mode O_BINARY fixed the issue - which will apply to the whole MinGW
porting problem - native under windows files need to be written and read
binary to make things portable.

Could any brave person willing to test the interface (preferably on a
fresh Cygwin, fresh GRASS for Cygwin, fresh R 1.6.2 (with some extra
packages - akima at least), contact me, and I'll let you have a link to
where I'll post the MinGW R/GRASS interface binary package? At the moment 
the Cygwin prefix is hardwired to "c:/cygwin" - this will be made 
user-settable soon.

Roger

> 
> Luck.
> 
Yes, indeed! Luck plus grass5 means results!


-- 
Roger Bivand
Economic Geography Section, Department of Economics, Norwegian School of
Economics and Business Administration, Breiviksveien 40, N-5045 Bergen,
Norway. voice: +47 55 95 93 55; fax +47 55 95 93 93
e-mail: Roger.Bivand at nhh.no