Hi,
I really like the GEOS-based enhancements to v.select and in the discussion of bug #1464 [1], it also seems that buffers only work correctly when using the GEOS library. Both of these alone seem sufficient to me to warrant making GEOS a mandatory dependency for GRASS.
Or at least, I would like to plead to packagers to compile with-geos.
Moritz
GEOS is a beast to compile on MinGW though, so creating
Windows binaries using open source tools might get
considerably harder with this added dependency.
This issue might resolve itself in the future, provided
that MinGW support improves.
Ben
On 11/04/2012 10:17 PM, Moritz Lennert wrote:
Hi,
I really like the GEOS-based enhancements to v.select and in the
discussion of bug #1464 [1], it also seems that buffers only work
correctly when using the GEOS library. Both of these alone seem
sufficient to me to warrant making GEOS a mandatory dependency for GRASS.Or at least, I would like to plead to packagers to compile with-geos.
Moritz
[1] http://trac.osgeo.org/grass/ticket/1464
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
--
Benjamin Ducke
{*} Geospatial Consultant
{*} GIS Developer
benducke@fastmail.fm
Hi,
2012/11/4 Benjamin Ducke <benducke@fastmail.fm>:
GEOS is a beast to compile on MinGW though, so creating
Windows binaries using open source tools might get
considerably harder with this added dependency.This issue might resolve itself in the future, provided
that MinGW support improves.
note that GEOS is provided through OSGeo4W framework [1] and winGRASS
is compiled against GEOS [2].
Martin
[1] http://trac.osgeo.org/osgeo4w/wiki/pkg-geos
[2] http://trac.osgeo.org/grass/browser/grass/branches/releasebranch_6_4/mswindows/osgeo4w/package.sh#L131
--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa
Thanks Martin, I shall take a look and see
if I can learn anything from their Makefiles.
However, I fear that they used VC:
http://trac.osgeo.org/osgeo4w/wiki/pkg-geos
so there might be some problems replicating this
with MinGW.
This might be a but "puritanical" of me, but
I really think that all of GRASS' mandatory
dependencies on Windows should compile easily
using MinGW, and not require proprietary
tools.
Cheers,
Ben
On 11/04/2012 10:52 PM, Martin Landa wrote:
Hi,
2012/11/4 Benjamin Ducke <benducke@fastmail.fm>:
GEOS is a beast to compile on MinGW though, so creating
Windows binaries using open source tools might get
considerably harder with this added dependency.This issue might resolve itself in the future, provided
that MinGW support improves.note that GEOS is provided through OSGeo4W framework [1] and winGRASS
is compiled against GEOS [2].Martin
[1] http://trac.osgeo.org/osgeo4w/wiki/pkg-geos
[2] http://trac.osgeo.org/grass/browser/grass/branches/releasebranch_6_4/mswindows/osgeo4w/package.sh#L131--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa
--
Benjamin Ducke
{*} Geospatial Consultant
{*} GIS Developer
benducke@fastmail.fm
Hi,
2012/11/4 Benjamin Ducke <benducke@fastmail.fm>:
This might be a but "puritanical" of me, but
I really think that all of GRASS' mandatory
dependencies on Windows should compile easily
using MinGW, and not require proprietary
tools.
AFAIK also GDAL is compiled for OSGeo4W using VC.
Martin
--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa
Hi,
2012/11/4 Benjamin Ducke <benducke@fastmail.fm>:
This might be a but "puritanical" of me, but
I really think that all of GRASS' mandatory
dependencies on Windows should compile easily
using MinGW, and not require proprietary
tools.
sorry, probably I am not getting the point. Then you would need to
recompile major part of OSGeo4W packages (due to VC).
Martin
--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa
I maintain a separate set of GRASS Windows
binaries, for use from within gvSIG/SEXTANTE.
Those are compiled from scratch, using only MinGW.
I like to avoid proprietary tools.
It's pretty straight-forward these days to
get the mandatory dependencies and most
GDAL drivers compiled using MinGW and MSYS.
Indeed: MinGW and VC DLLs do not mix well, so
it's better to compile everything with either
one or the other.
Ben
On 11/04/2012 11:25 PM, Martin Landa wrote:
Hi,
2012/11/4 Benjamin Ducke <benducke@fastmail.fm>:
This might be a but "puritanical" of me, but
I really think that all of GRASS' mandatory
dependencies on Windows should compile easily
using MinGW, and not require proprietary
tools.sorry, probably I am not getting the point. Then you would need to
recompile major part of OSGeo4W packages (due to VC).Martin
--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa
--
Benjamin Ducke
{*} Geospatial Consultant
{*} GIS Developer
benducke@fastmail.fm
Hi Ben,
On Sun, 04. Nov 2012 at 23:32:41 +0100, Benjamin Ducke wrote:
Indeed: MinGW and VC DLLs do not mix well,
In what way?
An important thing is to use the right function to release memory (G_free(),
GEOSFree(), CPLFree()...). Simply using free() might crash on windows, but
that IMHO should be considered a bug anyway.
Jürgen
--
Jürgen E. Fischer norBIT GmbH Tel. +49-4931-918175-31
Dipl.-Inf. (FH) Rheinstraße 13 Fax. +49-4931-918175-50
Software Engineer D-26506 Norden http://www.norbit.de
committ(ed|ing) to Quantum GIS IRC: jef on FreeNode
--
norBIT Gesellschaft fuer Unternehmensberatung und Informationssysteme mbH
Rheinstrasse 13, 26506 Norden
GF: Jelto Buurman, HR: Amtsgericht Emden, HRB 5502
Jürgen --
The problems are mostly with linking compiled C++
code. Due to the different name mangling schemes,
a DLL produced by VC might not be usable by
an EXE produced with MinGW and vice versa.
There are tools to work around that:
http://www.mingw.org/wiki/MSVC_and_MinGW_DLLs
I have tried and it works -- sometimes.
Anyway, it's a wasted effort for me, as I prefer
to fix source code and configure files so that
everything compiles cleanly using MinGW.
Why should using the C standard lib's free() a bug?
Cheers,
Ben
On 11/05/2012 12:38 AM, Jürgen E. Fischer wrote:
Hi Ben,
On Sun, 04. Nov 2012 at 23:32:41 +0100, Benjamin Ducke wrote:
Indeed: MinGW and VC DLLs do not mix well,
In what way?
An important thing is to use the right function to release memory (G_free(),
GEOSFree(), CPLFree()...). Simply using free() might crash on windows, but
that IMHO should be considered a bug anyway.Jürgen
--
Benjamin Ducke
{*} Geospatial Consultant
{*} GIS Developer
benducke@fastmail.fm
Hi Benjamin,
On Mon, 05. Nov 2012 at 08:36:18 +0100, Benjamin Ducke wrote:
The problems are mostly with linking compiled C++
code. Due to the different name mangling schemes,
a DLL produced by VC might not be usable by
an EXE produced with MinGW and vice versa.
Right, C++ is a different beast. I was assuming we were talking about C.
Why should using the C standard lib's free() a bug?
Because just using free() on something that should be released with some
specific function assumes that that function is just a wrapper around free().
That might not be the case or might change over time. It also ignores the fact
that there can be multiple heap managements like on windows, when multiple
compiler versions (and therefore their RTL) are used.
Jürgen
--
Jürgen E. Fischer norBIT GmbH Tel. +49-4931-918175-31
Dipl.-Inf. (FH) Rheinstraße 13 Fax. +49-4931-918175-50
Software Engineer D-26506 Norden http://www.norbit.de
committ(ed|ing) to Quantum GIS IRC: jef on FreeNode
--
norBIT Gesellschaft fuer Unternehmensberatung und Informationssysteme mbH
Rheinstrasse 13, 26506 Norden
GF: Jelto Buurman, HR: Amtsgericht Emden, HRB 5502
{snip}
Why should using the C standard lib's free() a bug?
Because just using free() on something that should be released with some
specific function assumes that that function is just a wrapper around free().
That might not be the case or might change over time. It also ignores the fact
that there can be multiple heap managements like on windows, when multiple
compiler versions (and therefore their RTL) are used.
Right, I get that. I was unaware of the issue
with different heap managements. Thanks for
pointing that one out.
Cheers,
Ben
Jürgen
--
Benjamin Ducke
{*} Geospatial Consultant
{*} GIS Developer
benducke@fastmail.fm
Benjamin Ducke wrote:
> > Indeed: MinGW and VC DLLs do not mix well,
>
> In what way?The problems are mostly with linking compiled C++
code. Due to the different name mangling schemes,
a DLL produced by VC might not be usable by
an EXE produced with MinGW and vice versa.
It isn't the name-mangling per se that's the problem. Unlike C, C++
doesn't have a defined ABI, so code generated by one compiler
typically won't be compatible with code generated by another compiler.
The differences in name mangling are so that you don't accidentally
use incompatible libraries.
--
Glynn Clements <glynn@gclements.plus.com>