[Gdal-dev] apps / MinGW

[Frank Warmerdam]

Radim Blazek wrote:
> It has that efect that it works.
> 
>> If the problem is in the GRASS libraries calls
>> to fopen() (or open() perhaps?) then that is where the fix would have to be.
>
> The problem is that in the GRASS libraries _fmode = _O_BINARY;
> is set but it is ignored if an application is linked to DLL.
> I would prefer to fix that in the GRASS library but I dont know how.
> Do you have any idea? The library is using open().


Radim,

Ah! I get it, _fmode is a global variable.  I gather setting it to
_O_BINARY forces all file IO to be binary by default?

Well, it seems the correct solution is to reengineer all GRASS IO open
calls to go somewhere that you can do something appropriate on win32 -
whether that be passing "b" in the access string, O_BINARY in the mode for
open() or using the native win32 file api (likely not practical).  I imagine
this will hard to do.

Putting your _fmode stuff in gdalinfo isn't going to fix other GDAL utilities
like gdal_translate, or stuff like python wrappers.  It also won't help
applications using GDAL (such as MapServer).

Sorry I don't have a good solution either, but in my opinion you are
running into problems with the GRASS assumption of a unix platform and
insufficient effort all those years ago to centralize stuff that could
be a portability problem.

Best regards,
-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | President OSGF, http://osgeo.org