[GRASS-dev] portable.h elimination

[Glynn Clements]

Paul Kelly wrote:

> >> I've modified lib/vector/diglib to determine the byte ordering at run
> >> time, rather than generating the portable.h header file.
> >>
> >> The supplied test case passes. It might be useful to test it using dig
> >> files generated on an architecture with the opposite byte order (I
> >> have no way to test this). It might also be worth testing it on MinGW.
> >
> > How should I test ?
> 
> Thanks for reminding me about this Moritz - I'd looked at it both quite a 
> while ago and more recently after Glynn posted about the portable.h 
> changes. I don't think there's any change on MinGW - the portable test in 
> the lib/vector/diglib Makefile always failed anyway - presumably that's 
> why it was conditionalised on not running on MinGW. If it is forced to run 
> anyway, I get the following output:

> For some reason (can't quite remember why) I changed test.c in the past to 
> try and get this to work. ISTR someone suggested somewhere extra seeks 
> were needed on Windows.

You need to seek when switching between reading and writing. Windows'
FILE structure only has a single buffer (rather than separate
read/write buffers), so you need to force it to flush/discard any
buffered data.

> This is what I changed:

Can you commit those, please.

> And with that the output from the test is now:
> 
> ==============TEST=============
> gcc -L/c/grass/grass6/dist.i686-pc-mingw32/lib -Wl,--export-dynamic,--enable-runtime-pseudo-reloc  -L/c/grass/forgrass/lib     -I/c/grass/forgrass/include -g -O2  -I/c/grass/forgrass/include -I/c/grass/forgrass/include  -I/c/grass/grass6/dist.i686-pc-mingw32/include  -o OBJ.i686-pc-mingw32/test test.c -lgrass_dig2 -lgrass_gis -lgrass_datetime -lxdr -liberty -lws2_32    -lz     -lgrass_rtree  -lgrass_rtree \
>  			-lgrass_gis -lgrass_datetime -lxdr -liberty -lws2_32    -lz     -lgrass_datetime  -lxdr -liberty -lws2_32    -lz
> cd OBJ.i686-pc-mingw32; PATH=".:/bin:/mingw/bin:/mingw/lib:/c/grass/forgrass/bin:/c/grass/forgrass/lib:/c/tcl/bin:/c/WINDOWS/system32:/c/WINDOWS:/c/WINDOWS/System32/Wbem:/c/Program Files/QuickTime/QTSystem/:/c/grass/forgrass/bin:/c/grass/forgrass/lib:/c/tcl/bin:/c/WINDOWS/system32:/c/WINDOWS:/c/WINDOWS/System32/Wbem:/c/Program Files/QuickTime/QTSystem/:/c/jed09916/bin:/c/grass/grass6/dist.i686-pc-mingw32/lib" ./test; diff ./test.tmp ../test.ok
> Binary files ./test.tmp and ../test.ok differ
> make: *** [OBJ.i686-pc-mingw32/test] Error 1
> 
> i.e. the test files are still different, but it doesn't have lots of 
> errors while running. I have no idea if/how that is significant!

The stream of errors indicates that what was read back doesn't match
what was written, i.e. a problem with low-level I/O.

The "diff" failure indicates that what was written wasn't what was
expected. This could be a text/binary issue (I don't see $(FMODE_OBJ)
in the link command); it could even be due to differences in
floating-point rounding (even if only the lowest bit of a double is
wrong, the test will still fail).

If adding $(FMODE_OBJ) to the test doesn't work, convert test.tmp and
test.ok to hex (with "od -t x ...") and compare the hex dumps.

-- 
Glynn Clements <glynn at gclements.plus.com>