Opened 12 years ago

Closed 4 years ago

#1983 closed defect (fixed)

GRASS support for windows

Reported by: jef Owned by: warmerdam
Priority: normal Milestone:
Component: GDAL_Raster Version: svn-trunk
Severity: normal Keywords: grass
Cc: Mateusz Łoskot

Description

I extend the nmake files to build a GRASS enabled GDAL for the Visual C++ build of QGIS. The patch also addresses what I think is a bug in the GRASS driver. It uses free() instead of G_free() for memory allocated with GRASS' G_store(). Which breaks for me when using GRASS DLLs.

Building the GRASS DLLs for QGIS is currently a kludge as GRASS doesn't support Visual C++. See https://svn.qgis.org/trac/browser/trunk/qgis/src/providers/grass/vc/.

Attachments (1)

gdal.diff (5.3 KB) - added by jef 12 years ago.
enable GRASS in Visual C++ build

Download all attachments as: .zip

Change History (9)

Changed 12 years ago by jef

Attachment: gdal.diff added

enable GRASS in Visual C++ build

comment:1 Changed 11 years ago by Mateusz Łoskot

Cc: Mateusz Łoskot added
Keywords: grass added

comment:2 Changed 11 years ago by Markus Neteler

The free() versus G_free() isn't a real problem, since:

/**
 * \brief Free allocated memory.
 *
 * \param[in,out] buf buffer holding original data
 */

void G_free(void *buf)
{
    free(buf);
}

On the other changes I cannot comment (no experience). In general it might be good to use the GRASS plugin in GDAL.

Sate of winGRASS which includes GDAL: http://grass.osgeo.org/wiki/WinGRASS_Current_Status

Markus

comment:3 in reply to:  2 Changed 11 years ago by jef

Replying to neteler:

The free() versus G_free() isn't a real problem, since:

/**
 * \brief Free allocated memory.
 *
 * \param[in,out] buf buffer holding original data
 */

void G_free(void *buf)
{
    free(buf);
}

That actually _IS_ the problem. On Windows (at least for MSVC) the memory management comes in at least two versions: release and debug.

The heap management of both is incompatible, therefore you need to use the free() from the same version the memory was malloc()ed with.

Using G_free() takes care of that, whereas calling free() from a DLL might call a different version and break.

comment:4 Changed 11 years ago by warmerdam

Status: newassigned
Type: enhancementdefect

Pursuing the G_free() aspect. I'm not convinced the build changes are appropriate as they stand.

comment:5 Changed 11 years ago by warmerdam

The code changes have bee applied in trunk (r15584) and 1.5 branch (r15585).

The build system changes seem to be lacking a new gdal/frmts/grass/makefile.vc, and also are not condition on define of the GRASS macros and can't be applied "as is". So I'm putting that off. I don't have a convenient setup for testing GRASS builds on win32 at this time so I'm also not in a good position to work through the details myself.

So the remaining issues (win32 build system) are pushed to the backburner again.

comment:6 Changed 5 years ago by Jukka Rahkonen

Does GRASS support work on Windows nowadays? Yes -> close the ticket, No -> describe the current situation.

comment:7 Changed 4 years ago by Jukka Rahkonen

Repeating my previous question.

comment:8 Changed 4 years ago by Even Rouault

Resolution: fixed
Status: assignedclosed

I'm afraid with the trac upgrade a lot of people no longer receive Trac notifications. Let's close that one.

Note: See TracTickets for help on using tickets.