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

Eric G. Miller egm2 at jps.net
Thu Feb 13 22:39:14 EST 2003


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...

Luck.
-- 
echo ">gra.fcw at 2ztr< eryyvZ .T pveR" | rot13 | reverse




More information about the grass-dev mailing list