[GRASS-dev] Re: winGRASS

mlennert · December 14, 2006, 5:12pm

Trying again, this time controlling my fingers a bit better

On Thu, December 14, 2006 16:15, Paul Kelly wrote:

On Thu, 14 Dec 2006, Moritz Lennert wrote:

It is in /mingw/share/bison/m4sugar/m4sugar.m4. I don't know why it is
looking for it in msys ? This causes an error in the compilation of

libvect and so many consequent errors.

Ah OK. I think I hacked about with that a little bit come to think of

it.

Just put it where it's looking for it

I'll try as mentioned above. If that doesn't help, I'll move it around.

It is installed in c:\msys\1.0\share.
I copied everything to c:\msys\share.

But I still get the same error. When I try to access /msys from within the
msys shell window, I also get an error. I actually have to do /c/msys

to get

there. But I just can't find where the path is coded...

Hmm I think when I had the problem it was looking for

/usr/share/bison/... So I don't understand. Must be some installation
thing; really don't know.

Actually the problem was that msys was installed as /msys/1.0/ instead of
just /msys. Solved that by moving around msys directories. Now no more
bison errors.

Yes, saw an error on that. Will try to figure out how to change the

makefile.

I haven't really found out how to change this. Currently the Makefile

contains:

# some definitions
SECT = 1
MANDIR = $(GISBASE)/man/man$(SECT)
HTMLDIR = $(GISBASE)/docs/html
HTML2MAN = GRASS_PERL=${PERL} VERSION_NUMBER=${GRASS_VERSION_NUMBER} sh

$(GRASS_HOME)/tools/g.html2man/g.html2man

MANPAGES := $(patsubst $(HTMLDIR)/%.html,$(MANDIR)/%.$(SECT),$(wildcard

$(HTMLDIR)/*.html))

default: $(MANDIR) $(MANPAGES)

$(MANDIR):
$(MKDIR) $(MANDIR)

$(MANDIR)/%.$(SECT): $(HTMLDIR)/%.html
$(HTML2MAN) $< $@ $(SECT)

The problem is in the last line where g.html2man is called. just

commenting

out the last line doesn't seem to work:

You maybe need the line to still start with a Tab, then comment out the

rest? I don't know. But tider probably to just delete

$(MANDIR) $(MANPAGES) after default:

Did that and it works.

Now the only errors I get are the following. Of these all are probably
expected, or ? (The gui/tcltk/menus is an issue of the Makefile not being
updated when the common menus were removed. Needs to be fixed in CVS.)

/c/grasssrc/grass6/display/drivers/PNG (undefined reference to `LIB_main')
/c/grasssrc/grass6/gui/tcltk/menus
/c/grasssrc/grass6/imagery/i.class (most of the following with sys/wait.h:
No such file or directory)
/c/grasssrc/grass6/imagery/i.ortho.photo/photo.2image
/c/grasssrc/grass6/imagery/i.ortho.photo/photo.2target
/c/grasssrc/grass6/imagery/i.points
/c/grasssrc/grass6/imagery/i.vpoints
/c/grasssrc/grass6/raster/r.li/r.li.daemon
/c/grasssrc/grass6/raster/r.li/r.li.edgedensity
/c/grasssrc/grass6/raster/r.li/r.li.patchdensity
/c/grasssrc/grass6/raster/r.li/r.li.patchnumber
/c/grasssrc/grass6/raster/r.li/r.li.shape
/c/grasssrc/grass6/raster/r.li/r.li.simpson
/c/grasssrc/grass6/raster/r.li/r.li.shannon
/c/grasssrc/grass6/raster/r.li/r.li.meanPatchSize
/c/grasssrc/grass6/raster/r.li/r.li.meanPixelAttribute
/c/grasssrc/grass6/raster/r.li/r.li.patchAreaDistributionCV
/c/grasssrc/grass6/raster/r.li/r.li.patchAreaDistributionSD
/c/grasssrc/grass6/raster/r.li/r.li.patchAreaDistributionRANGE
/c/grasssrc/grass6/raster/r.li/r.li.contrastWeightedEdgeDensity
/c/grasssrc/grass6/raster/r.li/r.li.richness
/c/grasssrc/grass6/raster/r.li/r.li.dominance
/c/grasssrc/grass6/raster/r.terraflow (grass2str.h:436: error: `getrusage'
undeclared (first use this function))

Other than that I get a running binary which I can launch from within

msys.

Launching it with grass63.bat does not seem to work. I don't get the

startup

screen and I get a message about g.dirsep not being found.

Oops - I forgot to add g.dirseps to the list of modules compiled by

default in general/Makefile. If you just change into the g.dirseps
directory and run make perhaps it will work after that. Remember to
check that you need backslashes in the WINGISBASE path in grass63.bat.

Did that. I also added a 'set GRASS_WISH=' command in grass63.bat, as it
didn't seem to find my wish command.

Now I see a message in cmd.exe: ERROR: LOCATION_NAME not set and an empty
'gis_set' window. When I close that window, the gis.m starts up but then
crashes and closes very quickly.

Launching grass63 within msys, I see the following issues at first glance:

- the dbf driver now launches (I can see the terminal window flashing),
but I get a 'dbmi: Protocol error', be for 'v.info -c' or for
'v.db.select'. Don't know how to debug this. I'll have to install
postgresql or sqlite to test with other db backends.

- everytime I a map display gets refreshed, I see 'etc/freetypecap: No
FreeType definition file

- v.buffer fails with a windows error while the topology is being built.
Launching v.build on the resulting file I get the warning that the coor
file of the map is larger than it should be

So, very promising as compilation seems to work, and I can already nicely
display and overlay maps. The dbmi error keeps me from using several of
the vector modules (v.buffer, v.overlay). I've tried a few raster modules
randomly (shaded relief, raster buffer, r.bilinear) and they worked.

Moritz

Paul_Kelly · December 14, 2006, 5:39pm

On Thu, 14 Dec 2006, Moritz Lennert wrote:

[...]

Now the only errors I get are the following. Of these all are probably
expected, or ? (The gui/tcltk/menus is an issue of the Makefile not being
updated when the common menus were removed. Needs to be fixed in CVS.)

/c/grasssrc/grass6/display/drivers/PNG (undefined reference to `LIB_main')
/c/grasssrc/grass6/gui/tcltk/menus
/c/grasssrc/grass6/imagery/i.class (most of the following with sys/wait.h:
No such file or directory)
/c/grasssrc/grass6/imagery/i.ortho.photo/photo.2image
/c/grasssrc/grass6/imagery/i.ortho.photo/photo.2target
/c/grasssrc/grass6/imagery/i.points
/c/grasssrc/grass6/imagery/i.vpoints
/c/grasssrc/grass6/raster/r.li/r.li.daemon
/c/grasssrc/grass6/raster/r.li/r.li.edgedensity
/c/grasssrc/grass6/raster/r.li/r.li.patchdensity
/c/grasssrc/grass6/raster/r.li/r.li.patchnumber
/c/grasssrc/grass6/raster/r.li/r.li.shape
/c/grasssrc/grass6/raster/r.li/r.li.simpson
/c/grasssrc/grass6/raster/r.li/r.li.shannon
/c/grasssrc/grass6/raster/r.li/r.li.meanPatchSize
/c/grasssrc/grass6/raster/r.li/r.li.meanPixelAttribute
/c/grasssrc/grass6/raster/r.li/r.li.patchAreaDistributionCV
/c/grasssrc/grass6/raster/r.li/r.li.patchAreaDistributionSD
/c/grasssrc/grass6/raster/r.li/r.li.patchAreaDistributionRANGE
/c/grasssrc/grass6/raster/r.li/r.li.contrastWeightedEdgeDensity
/c/grasssrc/grass6/raster/r.li/r.li.richness
/c/grasssrc/grass6/raster/r.li/r.li.dominance
/c/grasssrc/grass6/raster/r.terraflow (grass2str.h:436: error: `getrusage'
undeclared (first use this function))

Yes I get all those errors too. display/drivers/PNG is unsolveable for now but the others will be worth looking into.

[...]

Did that. I also added a 'set GRASS_WISH=' command in grass63.bat, as it
didn't seem to find my wish command.

Now I see a message in cmd.exe: ERROR: LOCATION_NAME not set and an empty
'gis_set' window. When I close that window, the gis.m starts up but then
crashes and closes very quickly.

Perhaps you have a corrupt GISRC file from the intitial g.dirseps problem? The init.bat doesn't do anything yet to delete corrupt GISRC files like Init.sh does - you could try deleting it manually and then restarting: %HOME%\.grassrc6 is the relevant file.

Launching grass63 within msys, I see the following issues at first glance:

- the dbf driver now launches (I can see the terminal window flashing),
but I get a 'dbmi: Protocol error', be for 'v.info -c' or for
'v.db.select'. Don't know how to debug this. I'll have to install
postgresql or sqlite to test with other db backends.

OK - I don't think I have ever used any database features at all so haven't tested this.

- everytime I a map display gets refreshed, I see 'etc/freetypecap: No
FreeType definition file

Yes I get that too. Would like to include freetype for a binary distribution.

- v.buffer fails with a windows error while the topology is being built.
Launching v.build on the resulting file I get the warning that the coor
file of the map is larger than it should be

Just thinking - the portability tests during the build of the vector library seem to fail. This would be worth looking into. TBH I haven't done must vector testing at all. Just with 3-D points as far as I can remember.

So, very promising as compilation seems to work, and I can already nicely
display and overlay maps. The dbmi error keeps me from using several of
the vector modules (v.buffer, v.overlay). I've tried a few raster modules
randomly (shaded relief, raster buffer, r.bilinear) and they worked.

Good to hear it

Paul

Markus_Neteler1 · December 14, 2006, 6:34pm

On Thu, Dec 14, 2006 at 06:12:35PM +0100, Moritz Lennert wrote:
...

(most of the following with sys/wait.h: No such file or directory)

I have conditionalized sys/wait.h in all files.

Markus

Glynn_Clements1 · December 14, 2006, 7:00pm

Paul Kelly wrote:

Just thinking - the portability tests during the build of the vector
library seem to fail. This would be worth looking into. TBH I haven't done
must vector testing at all. Just with 3-D points as far as I can remember.

IIRC, that's due to problems with MSVCRT's fseek() on files opened for
update (read/write).

AFAICT, you need to call fseek() or fflush() when switching between
reading and writing. I.e. read-then-write needs fseek() after the
read, while write-then-read needs either fseek() or fflush() after the
write. Using:

fseek(fp, 0, SEEK_CUR);

seems to work.

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

Markus_Neteler1 · December 14, 2006, 7:04pm

On Thu, Dec 14, 2006 at 06:12:35PM +0100, Moritz Lennert wrote:
...

/c/grasssrc/grass6/raster/r.terraflow (grass2str.h:436: error: `getrusage'
undeclared (first use this function))

Does including
#include <sys/time.h>
#include <sys/resource.h>
help? This is suggested by
man getrusage
on my Linux box.

Markus

Glynn_Clements1 · December 14, 2006, 10:04pm

Markus Neteler wrote:

> /c/grasssrc/grass6/raster/r.terraflow (grass2str.h:436: error: `getrusage'
> undeclared (first use this function))

Does including
#include <sys/time.h>
#include <sys/resource.h>
help? This is suggested by
man getrusage
on my Linux box.

getrusage() is Unix-specific; it doesn't exist on Windows (MinGW).

It's only required so that r.terraflow can write out CPU usage
information to the stats file.

AFAICT, it should only be necessary to modify the file
IOStream/include/rtimer.h; everything else treats Rtimer as opaque and
relies upon the rt_* macros.

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

H_B · December 14, 2006, 11:39pm

> /c/grasssrc/grass6/imagery/i.points
> /c/grasssrc/grass6/imagery/i.vpoints

both these require an interactive xmon, so not applicable for Windows sans X11.

Hamish

Glynn_Clements1 · December 15, 2006, 9:14am

Markus Neteler wrote:

On Thu, Dec 14, 2006 at 06:12:35PM +0100, Moritz Lennert wrote:
...
> (most of the following with sys/wait.h: No such file or directory)

I have conditionalized sys/wait.h in all files.

I can't see how that will help, as the files in question use fork()
and wait(), neither of which exist under MinGW.

As i.ortho.photo also requires an X monitor, it isn't likely to run
natively on Windows in the foreseeable future.

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

Markus_Neteler1 · December 15, 2006, 9:18am

On Fri, Dec 15, 2006 at 09:14:19AM +0000, Glynn Clements wrote:

Markus Neteler wrote:

> On Thu, Dec 14, 2006 at 06:12:35PM +0100, Moritz Lennert wrote:
> ...
> > (most of the following with sys/wait.h: No such file or directory)
>
> I have conditionalized sys/wait.h in all files.

I can't see how that will help, as the files in question use fork()
and wait(), neither of which exist under MinGW.

I took that from an existing GRASS module, it was not my
invention
At least it is now identical everywhere (lib/gis/ I left untouched).
If you have a suggestion to get it right, I can make a
new round to fix it.

As i.ortho.photo also requires an X monitor, it isn't likely to run
natively on Windows in the foreseeable future.

I understood that Brad is working on that. Maybe, integrated with
v.edit, this can be solved.

Markus

mlennert · December 15, 2006, 4:37pm

On Thu, December 14, 2006 18:39, Paul Kelly wrote:

On Thu, 14 Dec 2006, Moritz Lennert wrote:

[...]

Now the only errors I get are the following. Of these all are probably
expected, or ?

[...]

Yes I get all those errors too. display/drivers/PNG is unsolveable for now
but the others will be worth looking into.

Ok, some people have already given some ideas. Will ignore for now.

[...]

Did that. I also added a 'set GRASS_WISH=' command in grass63.bat, as it
didn't seem to find my wish command.

Now I see a message in cmd.exe: ERROR: LOCATION_NAME not set and an
empty
'gis_set' window. When I close that window, the gis.m starts up but then
crashes and closes very quickly.

Perhaps you have a corrupt GISRC file from the intitial g.dirseps problem?
The init.bat doesn't do anything yet to delete corrupt GISRC files like
Init.sh does - you could try deleting it manually and then restarting:
%HOME%\.grassrc6 is the relevant file.

Yep, that was it. Now GRASS starts without msys !

Next step: make install

- doesn't install the grass63.bat file in bin
- when I copy grass63.bat to c:\grass\bin and modify it so that
set WINGISBASE=c:\grass\grass-6.3.cvs
I get error in startup script: "can't read "env(GISBASE)": no such
variable while executing "source $env(GISBASE)/etc/gtcltk/gmsg.tcl" (file
"c:\grass\grass-6.3.cvs\etc\gis_set.tcl" line 29)

I don't know if the problem is that line 37 of Init.bat does not convert
the WINGISBASE variable correctly, or whether it is something else. But I
don't have this problem if I launch grass63.bat from the
bin.i686-pc-mingw32 in the source tree...

Step by step...

Moritz

Paul_Kelly · December 15, 2006, 5:01pm

On Fri, 15 Dec 2006, Moritz Lennert wrote:

Next step: make install

- doesn't install the grass63.bat file in bin
- when I copy grass63.bat to c:\grass\bin and modify it so that
set WINGISBASE=c:\grass\grass-6.3.cvs
I get error in startup script: "can't read "env(GISBASE)": no such
variable while executing "source $env(GISBASE)/etc/gtcltk/gmsg.tcl" (file
"c:\grass\grass-6.3.cvs\etc\gis_set.tcl" line 29)

Possibly that something goes wrong in init.bat because the demolocation directory doesn't get copied across during "make install"? I had been using the .grassrc63 file in there as a temporary GISRC file so g.dirseps would work. Need to find a clean solution to this - all it needs is a temporary file; it is fairly meaningless really. This ties in nicely with what Michael is looking at wrt a temporary GISRC file to make g.proj run!

If you copy across "demolocation/.grassrc63" to the install directory does it work? If so, that confirms the problem and we need to look at a more elegant solution with regard to the temporary GISRC files.

Paul

mlennert · December 15, 2006, 10:50pm

On Fri, December 15, 2006 18:01, Paul Kelly wrote:

On Fri, 15 Dec 2006, Moritz Lennert wrote:

Next step: make install

- doesn't install the grass63.bat file in bin
- when I copy grass63.bat to c:\grass\bin and modify it so that
set WINGISBASE=c:\grass\grass-6.3.cvs
I get error in startup script: "can't read "env(GISBASE)": no such
variable while executing "source $env(GISBASE)/etc/gtcltk/gmsg.tcl"
(file
"c:\grass\grass-6.3.cvs\etc\gis_set.tcl" line 29)

Possibly that something goes wrong in init.bat because the demolocation
directory doesn't get copied across during "make install"? I had been
using the .grassrc63 file in there as a temporary GISRC file so g.dirseps
would work. Need to find a clean solution to this - all it needs is a
temporary file; it is fairly meaningless really. This ties in nicely with
what Michael is looking at wrt a temporary GISRC file to make g.proj run!

If you copy across "demolocation/.grassrc63" to the install directory does
it work? If so, that confirms the problem and we need to look at a more
elegant solution with regard to the temporary GISRC files.

Will try this on Monday, when I have access to a windows machine again.

Moritz