[GRASS-dev] GRASS & cygwin quite slow

Hello,

(Please tell me if I should take this over to the grass-win list.)

After quite a long time of lobbying and a first presentation, my department here at the university is seriously thinking of moving towards GRASS, both for teaching and for research.

Now, several colleagues working in a MS Win environment would like to try GRASS. However, after having installed the Cygwin+GRASS combination (using the grass-cvs package from http://geni.ath.cx/grass.html) for several colleagues, I have noticed that GRASS is quite slow, at least diplaying vector maps. If I can't get this to speed up, it will be an immediate showstopper for most of my colleagues.

I know I could tell them to use QGIS, but currently, the capacities of QGIS in terms of vector mapping (which is what most of my colleagues do - currently mostly with ArcView) are just too limited compared to GRASS.
The other option is obviously to wait for the new GRASS python interface. But as the dynamic is launched now, I would hate to tell people: GRASS is great, just wait a bit.

So: is the cygwin solution slow because of the cygwin layer in between ? Because of the X-server ? What might be a solution to speed things up ?

Moritz

Moritz Lennert wrote:

Now, several colleagues working in a MS Win environment would like to
try GRASS. However, after having installed the Cygwin+GRASS combination
(using the grass-cvs package from http://geni.ath.cx/grass.html) for
several colleagues, I have noticed that GRASS is quite slow, at least
diplaying vector maps. If I can't get this to speed up, it will be an
immediate showstopper for most of my colleagues.

I know I could tell them to use QGIS, but currently, the capacities of
QGIS in terms of vector mapping (which is what most of my colleagues do
- currently mostly with ArcView) are just too limited compared to GRASS.
The other option is obviously to wait for the new GRASS python
interface. But as the dynamic is launched now, I would hate to tell
people: GRASS is great, just wait a bit.

So: is the cygwin solution slow because of the cygwin layer in between ?
Because of the X-server ? What might be a solution to speed things up ?

Are you displaying the maps with XDRIVER or with gis.m?

If you're using gis.m, the X server isn't involved in rendering the
maps; gis.m uses the PNG driver to render them into an image.

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

Moritz,

Currently, the GRASS TclTk GUI works without X11. Almost all GRASS modules
work without X11 or there is a TclTk replacement for critical modules.
v.digit is the only major exception now. NVIZ without X11 may still be in
transition. It still has problems on Intel Macs and I'm not sure about where
it is for Windows.

I hear that GRASS compiles under MinGW without X11.

What this all means is that with comparatively minimal work (compared to
rebuilding the entire GUI and any related links to C modules in wxPython),
GRASS **should** run natively under Windows with nearly all modules
functional. This ought to be a LOT faster than Cygwin.

We need some people to test and work on this. I believe that Glynn Clements
is working on it, but could probably use some collaborators.

I have very similar issues to yours. If we could get a native windows
version--for all the folks who prefer or are forced to use that platform--I
would have no problem justifying using GRASS in classes and getting
colleagues to try it. In many respects it is easier to use and teach than
ArcGIS.

Michael

__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics and Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

From: Moritz Lennert <mlennert@club.worldonline.be>
Date: Fri, 04 Aug 2006 14:14:00 +0200
To: Grass Developers List <grass-dev@grass.itc.it>
Subject: [GRASS-dev] GRASS & cygwin quite slow

Hello,

(Please tell me if I should take this over to the grass-win list.)

After quite a long time of lobbying and a first presentation, my
department here at the university is seriously thinking of moving
towards GRASS, both for teaching and for research.

Now, several colleagues working in a MS Win environment would like to
try GRASS. However, after having installed the Cygwin+GRASS combination
(using the grass-cvs package from http://geni.ath.cx/grass.html) for
several colleagues, I have noticed that GRASS is quite slow, at least
diplaying vector maps. If I can't get this to speed up, it will be an
immediate showstopper for most of my colleagues.

I know I could tell them to use QGIS, but currently, the capacities of
QGIS in terms of vector mapping (which is what most of my colleagues do
- currently mostly with ArcView) are just too limited compared to GRASS.
The other option is obviously to wait for the new GRASS python
interface. But as the dynamic is launched now, I would hate to tell
people: GRASS is great, just wait a bit.

So: is the cygwin solution slow because of the cygwin layer in between ?
Because of the X-server ? What might be a solution to speed things up ?

Moritz

Michael Barton wrote:

Currently, the GRASS TclTk GUI works without X11. Almost all GRASS modules
work without X11 or there is a TclTk replacement for critical modules.
v.digit is the only major exception now. NVIZ without X11 may still be in
transition. It still has problems on Intel Macs and I'm not sure about where
it is for Windows.

Executing external programs (e.g. using g.list to generate a list of
maps) doesn't work. The actual OpenGL rendering works fine.

I hear that GRASS compiles under MinGW without X11.

What this all means is that with comparatively minimal work (compared to
rebuilding the entire GUI and any related links to C modules in wxPython),
GRASS **should** run natively under Windows with nearly all modules
functional. This ought to be a LOT faster than Cygwin.

The main issue here is that gis.m would need to use the immediate
rendering provided by the new version of libraster. The MSVC runtime
doesn't include socket functions (and Windows itself doesn't support
Unix-domain sockets), so using a separate PNG driver won't work.

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

This bombs in the prototype wxPython UI too. Is this somehow different from
other GRASS modules?

Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics and Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

From: Glynn Clements <glynn@gclements.plus.com>
Date: Fri, 4 Aug 2006 22:47:16 +0100
To: Michael Barton <michael.barton@asu.edu>
Cc: Moritz Lennert <mlennert@club.worldonline.be>, Grass Developers List
<grass-dev@grass.itc.it>
Subject: Re: [GRASS-dev] GRASS & cygwin quite slow

Executing external programs (e.g. using g.list to generate a list of
maps) doesn't work. The actual OpenGL rendering works fine.

I hear that GRASS compiles under MinGW without X11.

Glynn Clements wrote:

> Currently, the GRASS TclTk GUI works without X11. Almost all GRASS modules
> work without X11 or there is a TclTk replacement for critical modules.
> v.digit is the only major exception now. NVIZ without X11 may still be in
> transition. It still has problems on Intel Macs and I'm not sure about where
> it is for Windows.

Executing external programs (e.g. using g.list to generate a list of
maps) doesn't work. The actual OpenGL rendering works fine.

> I hear that GRASS compiles under MinGW without X11.
>
> What this all means is that with comparatively minimal work (compared to
> rebuilding the entire GUI and any related links to C modules in wxPython),
> GRASS **should** run natively under Windows with nearly all modules
> functional. This ought to be a LOT faster than Cygwin.

The main issue here is that gis.m would need to use the immediate
rendering provided by the new version of libraster. The MSVC runtime
doesn't include socket functions (and Windows itself doesn't support
Unix-domain sockets), so using a separate PNG driver won't work.

Having finally managed to compile a recent version under Cygwin (since
updating Cygwin, --enable-shared no longer works), I've found another
reason to make gis.m use immediate rendering.

Cygwin implements Unix-domain sockets using TCP sockets. On my system,
the result is that running any d.* command pops up a ZoneAlarm dialog
asking me if the command should be allowed to make network
connections. This starts to get annoying rather quickly.

You only need to answer once per command, but that still means once
for the PNG driver, once for d.font, once for d.rast, etc. Also, if
you update an executable, ZoneAlarm tells you that the program has
changed and asks again. Needless to say, this is a significant
nuisance if you're recompiling GRASS regularly.

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

Michael Barton wrote:

> Executing external programs (e.g. using g.list to generate a list of
> maps) doesn't work. The actual OpenGL rendering works fine.

This bombs in the prototype wxPython UI too. Is this somehow different from
other GRASS modules?

Oops. The NVIZ map browser uses "ls", not g.list.

In any case, it appears to be a Tcl/Tk issue. The code works from a
normal wish shell, so something specific to the NVIZ code interferes
with the exec command.

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

Glynn Clements wrote:

> > Executing external programs (e.g. using g.list to generate a list of
> > maps) doesn't work. The actual OpenGL rendering works fine.
>
> This bombs in the prototype wxPython UI too. Is this somehow different from
> other GRASS modules?

Oops. The NVIZ map browser uses "ls", not g.list.

But that's irrelevant; it was getting stuck on calling g.gisenv to get
GISDBASE etc. I've discovered that it seems to blocking on stdin;
pressing Return in the terminal allows it to continue, until the next
exec. Furthermore, running nviz as "nviz ... </dev/null" eliminates
the problem. However, putting a redirection in the exec command itself
doesn't help.

Another major problem with MSys is that it uses its own virtual
filesystem rooted at e.g. c:/msys/1.0. The shell takes care of
translating command-line arguments, but this causes problems with
scripts which write pathnames to files. E.g. etc/Init.sh sets GISDBASE
in $GISRC to an MSys pathname (e.g. /home/glynn/grass-data) while the
executables (being native Windows programs) need the real pathname
(e.g. c:/msys/1.0/home/glynn/grass-data).

I suspect that we'll need to replace Init.sh with a .bat/.cmd file for
Windows. Either that, or find a shell which doesn't mess around with
filenames.

I'm not sure how this will affect other shell scripts. MSys' bash can
recognise Windows pathnames, and doesn't attempt to translate them, so
using e.g. GISDBASE=`g.gisenv GISDBASE` shouldn't be a problem. I
don't know whether any other scripts write pathnames to files, though.

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

Glynn Clements wrote:

Glynn Clements wrote:

Currently, the GRASS TclTk GUI works without X11. Almost all GRASS modules
work without X11 or there is a TclTk replacement for critical modules.
v.digit is the only major exception now. NVIZ without X11 may still be in
transition. It still has problems on Intel Macs and I'm not sure about where
it is for Windows.

Using the grass-cvs binaries from http://geni.ath.cx/grass.html which according to the web page date from April 17, 2006, even the gis.m seems to use X. At least, there is a large X in the top left of all the windows. The provided .bat file (http://geni.ath.cx/grass/grass61.bat) starts Xwin and then launches an xterm within that Xwin session.

So, how can I use the guis without X ?

Having finally managed to compile a recent version under Cygwin (since
updating Cygwin, --enable-shared no longer works), I've found another
reason to make gis.m use immediate rendering.

Cygwin implements Unix-domain sockets using TCP sockets. On my system,
the result is that running any d.* command pops up a ZoneAlarm dialog
asking me if the command should be allowed to make network
connections. This starts to get annoying rather quickly.

I can confirm this.

Moritz

Moritz Lennert wrote:

>>> Currently, the GRASS TclTk GUI works without X11. Almost all GRASS modules
>>> work without X11 or there is a TclTk replacement for critical modules.
>>> v.digit is the only major exception now. NVIZ without X11 may still be in
>>> transition. It still has problems on Intel Macs and I'm not sure about where
>>> it is for Windows.

Using the grass-cvs binaries from http://geni.ath.cx/grass.html which
according to the web page date from April 17, 2006, even the gis.m seems
to use X. At least, there is a large X in the top left of all the
windows. The provided .bat file (http://geni.ath.cx/grass/grass61.bat)
starts Xwin and then launches an xterm within that Xwin session.

So, how can I use the guis without X ?

1. Download the Tcl/Tk source code, and compile it. You might be able
to use the ActiveState Tcl/Tk package for gis.m, although I haven't
tried it. It's less likely that it would work with NVIZ. Cygwin's
Tcl/Tk *definitely* won't work with GRASS, due to the way it handles
filenames.

2. Download the GRASS source code, and compile it.

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

I found the latest CVS version does not compile under the last week's
Cygwin for some reasons. Maybe this problem has to do with the way of
building DLLs. Has anyone tried to compile CVS sources under Cygwin?

Huidae Cho

On Mon, Aug 07, 2006 at 08:39:18PM +0100, Glynn Clements wrote:

Moritz Lennert wrote:

> >>> Currently, the GRASS TclTk GUI works without X11. Almost all GRASS modules
> >>> work without X11 or there is a TclTk replacement for critical modules.
> >>> v.digit is the only major exception now. NVIZ without X11 may still be in
> >>> transition. It still has problems on Intel Macs and I'm not sure about where
> >>> it is for Windows.
>
> Using the grass-cvs binaries from http://geni.ath.cx/grass.html which
> according to the web page date from April 17, 2006, even the gis.m seems
> to use X. At least, there is a large X in the top left of all the
> windows. The provided .bat file (http://geni.ath.cx/grass/grass61.bat)
> starts Xwin and then launches an xterm within that Xwin session.
>
> So, how can I use the guis without X ?

1. Download the Tcl/Tk source code, and compile it. You might be able
to use the ActiveState Tcl/Tk package for gis.m, although I haven't
tried it. It's less likely that it would work with NVIZ. Cygwin's
Tcl/Tk *definitely* won't work with GRASS, due to the way it handles
filenames.

2. Download the GRASS source code, and compile it.

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

_______________________________________________
grass-dev mailing list
grass-dev@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass-dev

On Sat, Aug 05, 2006 at 07:49:40PM +0100, Glynn Clements wrote:

Glynn Clements wrote:

> > > Executing external programs (e.g. using g.list to generate a list of
> > > maps) doesn't work. The actual OpenGL rendering works fine.
> >
> > This bombs in the prototype wxPython UI too. Is this somehow different from
> > other GRASS modules?
>
> Oops. The NVIZ map browser uses "ls", not g.list.

But that's irrelevant; it was getting stuck on calling g.gisenv to get
GISDBASE etc. I've discovered that it seems to blocking on stdin;
pressing Return in the terminal allows it to continue, until the next
exec. Furthermore, running nviz as "nviz ... </dev/null" eliminates
the problem. However, putting a redirection in the exec command itself
doesn't help.

Another major problem with MSys is that it uses its own virtual
filesystem rooted at e.g. c:/msys/1.0. The shell takes care of
translating command-line arguments, but this causes problems with
scripts which write pathnames to files. E.g. etc/Init.sh sets GISDBASE
in $GISRC to an MSys pathname (e.g. /home/glynn/grass-data) while the
executables (being native Windows programs) need the real pathname
(e.g. c:/msys/1.0/home/glynn/grass-data).

Windows path name conflicts with the ":" path separator used in many
shell scripts. Is the native Windows version of GRASS supposed to run only
under MSys? If so, we can add /c/msys/1.0 prefix to all path names
stored in GISRC. I think it's reasonable to require MSys to run GRASS
on Windows.

Huidae Cho

I suspect that we'll need to replace Init.sh with a .bat/.cmd file for
Windows. Either that, or find a shell which doesn't mess around with
filenames.

I'm not sure how this will affect other shell scripts. MSys' bash can
recognise Windows pathnames, and doesn't attempt to translate them, so
using e.g. GISDBASE=`g.gisenv GISDBASE` shouldn't be a problem. I
don't know whether any other scripts write pathnames to files, though.

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

_______________________________________________
grass-dev mailing list
grass-dev@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass-dev

Huidae Cho wrote:

I found the latest CVS version does not compile under the last week's
Cygwin for some reasons. Maybe this problem has to do with the way of
building DLLs. Has anyone tried to compile CVS sources under Cygwin?

Yes. The --enable-shared stopped working after upgrading Cygwin. The
DLLs are built, the programs are built against them, but trying to run
a program results in nothing happening (no errors). Running the
program via gdb/strace results in a segfault.

AFAICT, this is a Cygwin issue. As it affects all programs, the only
GRASS changes to affect it would have to be related to libgis or the
build system, and I can't see anything suspicious in that area.

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

Huidae Cho wrote:

> > > > Executing external programs (e.g. using g.list to generate a list of
> > > > maps) doesn't work. The actual OpenGL rendering works fine.
> > >
> > > This bombs in the prototype wxPython UI too. Is this somehow different from
> > > other GRASS modules?
> >
> > Oops. The NVIZ map browser uses "ls", not g.list.
>
> But that's irrelevant; it was getting stuck on calling g.gisenv to get
> GISDBASE etc. I've discovered that it seems to blocking on stdin;
> pressing Return in the terminal allows it to continue, until the next
> exec. Furthermore, running nviz as "nviz ... </dev/null" eliminates
> the problem. However, putting a redirection in the exec command itself
> doesn't help.
>
> Another major problem with MSys is that it uses its own virtual
> filesystem rooted at e.g. c:/msys/1.0. The shell takes care of
> translating command-line arguments, but this causes problems with
> scripts which write pathnames to files. E.g. etc/Init.sh sets GISDBASE
> in $GISRC to an MSys pathname (e.g. /home/glynn/grass-data) while the
> executables (being native Windows programs) need the real pathname
> (e.g. c:/msys/1.0/home/glynn/grass-data).

Windows path name conflicts with the ":" path separator used in many
shell scripts. Is the native Windows version of GRASS supposed to run only
under MSys? If so, we can add /c/msys/1.0 prefix to all path names
stored in GISRC.

It would have to be c:/msys/1.0; the /c/<etc> syntax won't work with
MSVCRT functions (open() etc).

The main question is: in how many different places does this issue
arise? If it's just Init.sh, we can add a hack for MSys. If it's going
to keep cropping up, we need a more general solution.

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

(cd grass6 && make) stops at lib/vector/diglib when executing the test
program. It seems like it takes forever for executables to find DLL
exported symbols such as dig_set_cur_port(). It just stops there and
holds terminal. Killing the process four times in the Task Manager
actually stops it, but it happens again at some point (maybe it's
libgrass_dig again).

Huidae Cho

On Tue, Aug 08, 2006 at 12:59:19AM +0100, Glynn Clements wrote:

Huidae Cho wrote:

> I found the latest CVS version does not compile under the last week's
> Cygwin for some reasons. Maybe this problem has to do with the way of
> building DLLs. Has anyone tried to compile CVS sources under Cygwin?

Yes. The --enable-shared stopped working after upgrading Cygwin. The
DLLs are built, the programs are built against them, but trying to run
a program results in nothing happening (no errors). Running the
program via gdb/strace results in a segfault.

AFAICT, this is a Cygwin issue. As it affects all programs, the only
GRASS changes to affect it would have to be related to libgis or the
build system, and I can't see anything suspicious in that area.

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

On Tue, Aug 08, 2006 at 03:20:16AM +0100, Glynn Clements wrote:

Huidae Cho wrote:

> > > > > Executing external programs (e.g. using g.list to generate a list of
> > > > > maps) doesn't work. The actual OpenGL rendering works fine.
> > > >
> > > > This bombs in the prototype wxPython UI too. Is this somehow different from
> > > > other GRASS modules?
> > >
> > > Oops. The NVIZ map browser uses "ls", not g.list.
> >
> > But that's irrelevant; it was getting stuck on calling g.gisenv to get
> > GISDBASE etc. I've discovered that it seems to blocking on stdin;
> > pressing Return in the terminal allows it to continue, until the next
> > exec. Furthermore, running nviz as "nviz ... </dev/null" eliminates
> > the problem. However, putting a redirection in the exec command itself
> > doesn't help.
> >
> > Another major problem with MSys is that it uses its own virtual
> > filesystem rooted at e.g. c:/msys/1.0. The shell takes care of
> > translating command-line arguments, but this causes problems with
> > scripts which write pathnames to files. E.g. etc/Init.sh sets GISDBASE
> > in $GISRC to an MSys pathname (e.g. /home/glynn/grass-data) while the
> > executables (being native Windows programs) need the real pathname
> > (e.g. c:/msys/1.0/home/glynn/grass-data).
>
> Windows path name conflicts with the ":" path separator used in many
> shell scripts. Is the native Windows version of GRASS supposed to run only
> under MSys? If so, we can add /c/msys/1.0 prefix to all path names
> stored in GISRC.

It would have to be c:/msys/1.0; the /c/<etc> syntax won't work with
MSVCRT functions (open() etc).

You're right. I overlooked that only c:/ is working with MSVCRT.

The main question is: in how many different places does this issue
arise? If it's just Init.sh, we can add a hack for MSys. If it's going
to keep cropping up, we need a more general solution.

Another problem is with the path separator.
PATH="c:/msys/1.0/.../grass/bin" does not work since it's translated to
PATH="c;c:\msys\1.0\msys\1.0\...\grass\bin". MSVCRT functions use the
c:/msys/1.0 syntax, but once modules are compiled, they need
PATH=/c/msys/1.0 to find DLLs.

What I'm thinking is that everything can be done with the c:/msys/1.0
syntax including file I/O, but paths need to be converted to the
/c/msys/1.0 syntax whenever they are exported with putenv().

Huidae Cho

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

Huidae Cho wrote:

> The main question is: in how many different places does this issue
> arise? If it's just Init.sh, we can add a hack for MSys. If it's going
> to keep cropping up, we need a more general solution.

Another problem is with the path separator.
PATH="c:/msys/1.0/.../grass/bin" does not work since it's translated to
PATH="c;c:\msys\1.0\msys\1.0\...\grass\bin". MSVCRT functions use the
c:/msys/1.0 syntax, but once modules are compiled, they need
PATH=/c/msys/1.0 to find DLLs.

MSys (bash) automatically translates filenames when it thinks that's
the correct thing to do, so you set PATH=/c/msys/1.0/.../grass/bin (or
just PATH=/.../grass/bin) and the program will actually get the
Windows syntax.

E.g.:

  $ cat env.c
  #include <stdio.h>
  int main(void)
  {
          printf("%s\n", getenv("PATH"));
          return 0;
  }
  $ echo $PATH
  /usr/local/bin:/mingw/bin:/bin:/c/WINDOWS/system32:/c/WINDOWS:/c/WINDOWS/System32/Wbem
  $ ./env.exe
  C:\msys\1.0\local\bin;c:\mingw\bin;C:\msys\1.0\bin;c:\WINDOWS\system32;c:\WINDOWS;c:\WINDOWS\System32\Wbem

The problem is that it can't always figure out if something is meant
to be translated or not. E.g. with:

  echo "GISDBASE: $GISDBASE" > "$GISRC"

it doesn't treat the string as a filename, so it gets written
literally.

Some examples:

  $ GISDBASE=/home/glynn/grass-data

  $ echo $GISDBASE
  /home/glynn/grass-data

  $ /bin/echo $GISDBASE
  /home/glynn/grass-data

  $ ls -d $GISDBASE
  /home/glynn/grass-data

  $ /c/Cygwin/bin/ls.exe -d $GISDBASE
  C:/msys/1.0/home/glynn/grass-data

  $ /c/Cygwin/bin/echo.exe $GISDBASE
  C:/msys/1.0/home/glynn/grass-data

  $ /c/Cygwin/bin/echo.exe "GISDBASE:" $GISDBASE
  GISDBASE: C:/msys/1.0/home/glynn/grass-data

  $ /c/Cygwin/bin/echo.exe "GISDBASE: $GISDBASE"
  GISDBASE: /home/glynn/grass-data

  $ /c/Cygwin/bin/echo.exe foo=$GISDBASE
  foo=C:/msys/1.0/home/glynn/grass-data

It appears that:

1. When calling a built-in, running a bash script (e.g. /bin/echo),
or running an MSys executable, no translation occurs.

2. When running a non-MSys executable (e.g. Cygwin's echo.exe or ls.exe),
translation is performed if a complete argument looks like a filename.

3. Where a filename is only part of an argument, translation may or
may not be performed depending upon the exact form of the argument. I
have no idea whether the specifics are documented anywhere.

So the issue comes down to determining cases where pathnames may
passed through mechanisms which aren't subject to the necessary
conversions (or possibly which are converted but shouldn't be).

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

Huidae Cho wrote:

> > I found the latest CVS version does not compile under the last week's
> > Cygwin for some reasons. Maybe this problem has to do with the way of
> > building DLLs. Has anyone tried to compile CVS sources under Cygwin?
>
> Yes. The --enable-shared stopped working after upgrading Cygwin. The
> DLLs are built, the programs are built against them, but trying to run
> a program results in nothing happening (no errors). Running the
> program via gdb/strace results in a segfault.
>
> AFAICT, this is a Cygwin issue. As it affects all programs, the only
> GRASS changes to affect it would have to be related to libgis or the
> build system, and I can't see anything suspicious in that area.

(cd grass6 && make) stops at lib/vector/diglib when executing the test
program. It seems like it takes forever for executables to find DLL
exported symbols such as dig_set_cur_port(). It just stops there and
holds terminal. Killing the process four times in the Task Manager
actually stops it, but it happens again at some point (maybe it's
libgrass_dig again).

That's the first point in the build process where a GRASS executable
is run. I don't get a hang; the programs just do nothing. No output,
no error message, no delay.

I don't want to spend too much time on this right now in case it just
goes away by itself in the next Cygwin update. Cygwin does appear to
have adopted a slightly relaxed definition of "stable" recently (e.g.
changing the "stable" X release from 6.8.2 to 6.8.99.901).

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

Glynn Clements wrote:

Moritz Lennert wrote:

Currently, the GRASS TclTk GUI works without X11. Almost all GRASS modules
work without X11 or there is a TclTk replacement for critical modules.
v.digit is the only major exception now. NVIZ without X11 may still be in
transition. It still has problems on Intel Macs and I'm not sure about where
it is for Windows.

Using the grass-cvs binaries from http://geni.ath.cx/grass.html which according to the web page date from April 17, 2006, even the gis.m seems to use X. At least, there is a large X in the top left of all the windows. The provided .bat file (http://geni.ath.cx/grass/grass61.bat) starts Xwin and then launches an xterm within that Xwin session.

So, how can I use the guis without X ?

1. Download the Tcl/Tk source code, and compile it. You might be able
to use the ActiveState Tcl/Tk package for gis.m, although I haven't
tried it. It's less likely that it would work with NVIZ. Cygwin's
Tcl/Tk *definitely* won't work with GRASS, due to the way it handles
filenames.

2. Download the GRASS source code, and compile it.

Just to make sure: to do this, I need MinGW or MSys, or both ?

Moritz

Moritz Lennert wrote:

>>>>> Currently, the GRASS TclTk GUI works without X11. Almost all GRASS modules
>>>>> work without X11 or there is a TclTk replacement for critical modules.
>>>>> v.digit is the only major exception now. NVIZ without X11 may still be in
>>>>> transition. It still has problems on Intel Macs and I'm not sure about where
>>>>> it is for Windows.
>> Using the grass-cvs binaries from http://geni.ath.cx/grass.html which
>> according to the web page date from April 17, 2006, even the gis.m seems
>> to use X. At least, there is a large X in the top left of all the
>> windows. The provided .bat file (http://geni.ath.cx/grass/grass61.bat)
>> starts Xwin and then launches an xterm within that Xwin session.
>>
>> So, how can I use the guis without X ?
>
> 1. Download the Tcl/Tk source code, and compile it. You might be able
> to use the ActiveState Tcl/Tk package for gis.m, although I haven't
> tried it. It's less likely that it would work with NVIZ. Cygwin's
> Tcl/Tk *definitely* won't work with GRASS, due to the way it handles
> filenames.
>
> 2. Download the GRASS source code, and compile it.

Just to make sure: to do this, I need MinGW or MSys, or both ?

Both. You also need to build GDAL, PROJ, XDR, zlib from source (XDR
has to be the xdr-4.0-mingw2 package; the standard SunRPC distribution
uses socket functions which aren't present in the MSVC runtime). For
NVIZ, you also need to build Tcl/Tk.

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