[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