[GRASS-dev] GRASS and GDAL 1.4.1 MingW

GRASS GIS GRASS GIS developer
,
1

Hi all,

concerning the troubles with the DBF driver under Win32 that I wrote
about earlier, I am trying to compile a current version of GRASS
with MingW.

My problem is, that I cannot break the vicious GDAL-GRASS-GDAL cycle
anymore. I was trying to follow the instructions in the gdal-grass
plugin README:

1. GDAL 1.4.1 compiles fine without GRASS support.

2. However, the README is not clear on whether GRASS first needs to be
compiled w/o GDAL support firdst, but I assume it has to, because it
won't be able to find GDALOpen and the configure script aborts:

checking whether to use GDAL... yes
checking for gdal-config... /usr/local/bin/gdal-config
checking for GDALOpen... no
checking for GDALOpen... no
configure: error: *** couldn't find GDAL

3. Fair enough, BUT: with the current CVS version, it seems impossible
to compile GRASS without GDAL support, as compilation in lib/vector/Vlib
aborts, even if I specify --without-gdal:

field.c: In function `Vect_read_dblinks':
field.c:388: error: `OGRDataSourceH' undeclared (first use in this function)
field.c:388: error: (Each undeclared identifier is reported only once
field.c:388: error: for each function it appears in.)
field.c:388: error: syntax error before "Ogr_ds"
field.c:389: error: `OGRLayerH' undeclared (first use in this function)
field.c:390: error: `OGRFeatureDefnH' undeclared (first use in this
function)
field.c:400: error: `Ogr_ds' undeclared (first use in this function)
field.c:412: error: `Ogr_layer' undeclared (first use in this function)
field.c:417: error: `Ogr_featuredefn' undeclared (first use in this
function)

A 'make distclean' with fresh configure run did not help.

I don't know how many hours of time I have already lost with this
tricky GDAL-GRASS interdependency thing in the past without ever
figuring it out 100%
Are you all sure that including GDAL in the GRASS distribution in the
future is not an option?

Best,

Benjamin

--
Benjamin Ducke, M.A.
Archäoinformatik
(Archaeoinformation Science)
Institut für Ur- und Frühgeschichte
(Inst. of Prehistoric and Historic Archaeology)
Christian-Albrechts-Universität zu Kiel
Johanna-Mestorf-Straße 2-6
D 24098 Kiel
Germany

Tel.: ++49 (0)431 880-3378 / -3379
Fax : ++49 (0)431 880-7300
www.uni-kiel.de/ufg

2

Benjamin Ducke wrote:

2. However, the README is not clear on whether GRASS first needs to be
compiled w/o GDAL support firdst, but I assume it has to, because it
won't be able to find GDALOpen and the configure script aborts:

..

3. Fair enough, BUT: with the current CVS version, it seems impossible
to compile GRASS without GDAL support, as compilation in
lib/vector/Vlib aborts, even if I specify --without-gdal:

GDAL is now a formal dependency. compiling without it is a bad idea.

the order should be:
1. compile & install GDAL without grass support
2. compile & install GRASS linking to the new GDAL
3. compile & install GDAL's GRASS plugin linking to the new GRASS.

Are you all sure that including GDAL in the GRASS distribution in the
future is not an option?

Yes. That would just make things worse.

Hamish

3

Hamish wrote:

Benjamin Ducke wrote:

2. However, the README is not clear on whether GRASS first needs to be
compiled w/o GDAL support firdst, but I assume it has to, because it
won't be able to find GDALOpen and the configure script aborts:

..

3. Fair enough, BUT: with the current CVS version, it seems impossible
to compile GRASS without GDAL support, as compilation in
lib/vector/Vlib aborts, even if I specify --without-gdal:

GDAL is now a formal dependency. compiling without it is a bad idea.

the order should be:
1. compile & install GDAL without grass support
2. compile & install GRASS linking to the new GDAL
3. compile & install GDAL's GRASS plugin linking to the new GRASS.

Step 1: OK
Step 2: Fails:

checking for gdal-config... /usr/local/bin/gdal-config
checking for GDALOpen... no
checking for GDALOpen... no
configure: error: *** couldn't find GDAL

Would this be the time to remove --without-gdal from the configure
script?

Best,

Benjamin

--
Benjamin Ducke, M.A.
Archäoinformatik
(Archaeoinformation Science)
Institut für Ur- und Frühgeschichte
(Inst. of Prehistoric and Historic Archaeology)
Christian-Albrechts-Universität zu Kiel
Johanna-Mestorf-Straße 2-6
D 24098 Kiel
Germany

Tel.: ++49 (0)431 880-3378 / -3379
Fax : ++49 (0)431 880-7300
www.uni-kiel.de/ufg

4

I just tried installing the GDAL version contained in the
wingrass-extralibs package:

http://grass.gdf-hannover.de/wiki/WinGRASS_Current_Status

following the precise steps as outlined here:

http://grass.gdf-hannover.de/wiki/WinGRASS_Current_Status

With a fresh update of GRASS CVS

Still the same configure error:

checking for gdal-config... /usr/local/bin/gdal-config
checking for GDALOpen... no
checking for GDALOpen... no
configure: error: *** couldn't find GDAL

What am I doing wrong?

Benjamin

Benjamin Ducke wrote:

Hamish wrote:

Benjamin Ducke wrote:

2. However, the README is not clear on whether GRASS first needs to be
compiled w/o GDAL support firdst, but I assume it has to, because it
won't be able to find GDALOpen and the configure script aborts:

..

3. Fair enough, BUT: with the current CVS version, it seems impossible
to compile GRASS without GDAL support, as compilation in
lib/vector/Vlib aborts, even if I specify --without-gdal:

GDAL is now a formal dependency. compiling without it is a bad idea.

the order should be:
1. compile & install GDAL without grass support
2. compile & install GRASS linking to the new GDAL
3. compile & install GDAL's GRASS plugin linking to the new GRASS.

Step 1: OK
Step 2: Fails:

checking for gdal-config... /usr/local/bin/gdal-config
checking for GDALOpen... no
checking for GDALOpen... no
configure: error: *** couldn't find GDAL

Would this be the time to remove --without-gdal from the configure
script?

Best,

Benjamin

--
Benjamin Ducke, M.A.
Archäoinformatik
(Archaeoinformation Science)
Institut für Ur- und Frühgeschichte
(Inst. of Prehistoric and Historic Archaeology)
Christian-Albrechts-Universität zu Kiel
Johanna-Mestorf-Straße 2-6
D 24098 Kiel
Germany

Tel.: ++49 (0)431 880-3378 / -3379
Fax : ++49 (0)431 880-7300
www.uni-kiel.de/ufg

5

On Thu, 14 Jun 2007, Benjamin Ducke wrote:

I just tried installing the GDAL version contained in the
wingrass-extralibs package:

http://grass.gdf-hannover.de/wiki/WinGRASS_Current_Status

following the precise steps as outlined here:

http://grass.gdf-hannover.de/wiki/WinGRASS_Current_Status

With a fresh update of GRASS CVS

Still the same configure error:

checking for gdal-config... /usr/local/bin/gdal-config
checking for GDALOpen... no
configure: error: *** couldn't find GDAL

What am I doing wrong?

Look in config.log to see what the error is and you should be able to work it out from there. However I suspect you may need to change the paths at the top of the gdal-config script to match where you have actually installed it, rather than where I installed it before I generated wingrass-extralibs.tar.gz. It's not designed to be fool-proof, just a help to save effort in compiling all the other libraries. Although maybe long-term we could move away from using the gdal-config command in the configure script to get away from problems like this. I think everything its used for should probably be able to be achieved without it.

Paul

6

Cool. That fixed it. I think I am getting slowly to the point where
I understand all the details of the MinGW compile process.
I hope I'll be able to report back with some debugging news concerning
the Win32 DBF.EXE deadlocks soon.

Best, Benjamin

Paul Kelly wrote:

On Thu, 14 Jun 2007, Benjamin Ducke wrote:

I just tried installing the GDAL version contained in the
wingrass-extralibs package:

http://grass.gdf-hannover.de/wiki/WinGRASS_Current_Status

following the precise steps as outlined here:

http://grass.gdf-hannover.de/wiki/WinGRASS_Current_Status

With a fresh update of GRASS CVS

Still the same configure error:

checking for gdal-config... /usr/local/bin/gdal-config
checking for GDALOpen... no
checking for GDALOpen... no
configure: error: *** couldn't find GDAL

What am I doing wrong?

Look in config.log to see what the error is and you should be able to
work it out from there. However I suspect you may need to change the
paths at the top of the gdal-config script to match where you have
actually installed it, rather than where I installed it before I
generated wingrass-extralibs.tar.gz. It's not designed to be fool-proof,
just a help to save effort in compiling all the other libraries.
Although maybe long-term we could move away from using the gdal-config
command in the configure script to get away from problems like this. I
think everything its used for should probably be able to be achieved
without it.

Paul

--
Benjamin Ducke, M.A.
Archäoinformatik
(Archaeoinformation Science)
Institut für Ur- und Frühgeschichte
(Inst. of Prehistoric and Historic Archaeology)
Christian-Albrechts-Universität zu Kiel
Johanna-Mestorf-Straße 2-6
D 24098 Kiel
Germany

Tel.: ++49 (0)431 880-3378 / -3379
Fax : ++49 (0)431 880-7300
www.uni-kiel.de/ufg

7

Paul Kelly wrote:

Although maybe
long-term we could move away from using the gdal-config command in the
configure script to get away from problems like this. I think everything
its used for should probably be able to be achieved without it.

I wouldn't be so sure.

GDAL can require a *lot* of other libraries (by its nature, it's a
front-end to various raster data libraries), some of which might be in
non-obvious locations, and may have substantial dependencies of their
own.

AFAICT, the only alternative is to provide a --with-gdal-ldflags=
switch and require the user to specify exactly which flags are
required to link against GDAL.

Implementing such a switch would be straightforward; getting the
average user (or developer) to figure out what value to provide would
be rather less straightforward.

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

8

On 12/06/07 12:35, Benjamin Ducke wrote:

Hi all,

concerning the troubles with the DBF driver under Win32 that I wrote
about earlier, I am trying to compile a current version of GRASS
with MingW.

Just out of curiosity: any reason you do not wish to use the precompiled version available at:

http://moritz.homelinux.org/grass/wingrass/

I try to be more or less regular in providing packages based on the latest CVS (although the latest one is ten days old...I'll put up a new one tonight or tomorrow).

Moritz

9

Two reasons:

a) I want to be sure that I understand all details involved in the
compile process under MingW
b) I have a lot of custom code that I need to merge into the current
CVS tree and compile along with it, as GEM does not yet run w/o problems
with the MSYS based version of GRASS

... my ultimate goal is to create a version of the current CVS of GRASS
6.3 for use in archaeology. This will include all the additional modules
I have written for GRASS over the years.

But I will also keep testing your CVS packages as time allows.

Benjamin

Moritz Lennert wrote:

On 12/06/07 12:35, Benjamin Ducke wrote:

Hi all,

concerning the troubles with the DBF driver under Win32 that I wrote
about earlier, I am trying to compile a current version of GRASS
with MingW.

Just out of curiosity: any reason you do not wish to use the precompiled
version available at:

http://moritz.homelinux.org/grass/wingrass/

I try to be more or less regular in providing packages based on the
latest CVS (although the latest one is ten days old...I'll put up a new
one tonight or tomorrow).

Moritz

--
Benjamin Ducke, M.A.
Archäoinformatik
(Archaeoinformation Science)
Institut für Ur- und Frühgeschichte
(Inst. of Prehistoric and Historic Archaeology)
Christian-Albrechts-Universität zu Kiel
Johanna-Mestorf-Straße 2-6
D 24098 Kiel
Germany

Tel.: ++49 (0)431 880-3378 / -3379
Fax : ++49 (0)431 880-7300
www.uni-kiel.de/ufg