[GRASS-dev] writing msys capable grass63 startup script

GRASS GIS GRASS GIS developer
21

On Mon, 21 May 2007, Paolo Cavallini wrote:

Soory: whan you say this, what do you exactly mean? We are using the
qgis version, which has of course its limitations, but is very much
usable, and far easier for novices.

IIUC (please correct me if I'm wrong) the QGIS GRASS is not true native Windows GRASS as it relies on Msys being installed to support Unix-isms in the GRASS code? We are currently working on removing many of these in order to get GRASS working reliably on native Windows without any Unix sub-system present.

I really should install QGIS+GRASS and see exactly what it does though. Can anybody clarify?

I think diversity is a byproduct of freedom, and we have several ways at
hand.
pc
- --
Paolo Cavallini
http://www.faunalia.it/pc
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGUcDn/NedwLUzIr4RAmKuAKCU+2CyIoeIv36ZdHnW159b1cYoYACgu2AF
4gs1YeT/HStA6AFrAGMxwZw=
=01rN
-----END PGP SIGNATURE-----

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

22

On Mon, 21 May 2007, Glynn Clements wrote:

Michael Barton wrote:

Cygwin is the old, stopgap method to get GRASS running in some way under
windows. However, it is difficult to install, especially on lab machines and
often conflicts with Byzantine Windows security measures. I believe the
Cygwin is being maintained, but not being actively developed.

There's nothing to "develop".

Yes, just to re-iterate that point - I've been using GRASS on Cygwin for years (not recently though) and it is stable and full-featured. Have also introduced several non-Unix users to GRASS through Cygwin. In my experience though if people are scared of Unix, they won't like it. But it's a very viable option for using GRASS on Windows.

Paul

23

Hi,
Paul Kelly píše v Po 21. 05. 2007 v 21:40 +0100:

On Mon, 21 May 2007, Glynn Clements wrote:

[...]

Yes, just to re-iterate that point - I've been using GRASS on Cygwin for
years (not recently though) and it is stable and full-featured. Have also
introduced several non-Unix users to GRASS through Cygwin. In my
experience though if people are scared of Unix, they won't like it. But
it's a very viable option for using GRASS on Windows.

Paul

I would like to confirm this - I have the same experience. We teached
GRASS on MS Windows under cygwin and it worked well.

However - I'm looking forward to full featured, standalone native GRASS
on MS Windows :slight_smile:

Jachym
--
Jachym Cepicky
e-mail: jachym.cepicky@gmail.com
URL: http://les-ejk.cz
GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub

24

Once the wxgrass GUI gets to a semi-complete state (pretty soon actually), I
thought it would be a good exercise to try rebuilding a script or two in
python to see how it goes. I have the impression that it will be a lot
easier and use much less code than bash shell scripting to do complex things
and about the same amount of code to do simple things. If anyone wants to
try, I will help test.

Michael

On 5/21/07 12:11 PM, "Glynn Clements" <glynn@gclements.plus.com> wrote:

Moritz Lennert wrote:

This also means that any shell scripts (e.g. g.mremove, v.dissolve, etc)
will either have to be replaced by C-versions (which kind of defeats
their purpose of being easily codable for a larger number), be coded in
a cross-platform scripting language (e.g. Python), or anyone who wants
to use these under Windows has to provide access to a series of shell
tools (e.g. through Msys).

Personally, I would favour switching to Python.

Apart from the portability issues, both Bourne shell and C shell are
*really* poor as general-purpose programming languages.

If you just want to run a sequence of commands, then a shell saves you
the trouble of having to quote the arguments and prefix the command
with an "exec" (or similar) command, as would normally be the case for
a normal programming language.

As soon as you get beyond that, the fact that they were designed as
interactive shells first and programming languages second starts to
become a major problem.

__________________________________________
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

25

On Mon, May 21, 2007 13:58, Benjamin Ducke wrote:

1. The DBF driver deadlocks randomly!
Any GRASS module that needs to access the attribute table (DBF format)
of a vector map is prone to this: E.g. I tried running v.out.ogr on a
map with ca. 3000 points repeatedly. Out of ten runs, 2 or 3 deadlock at
a random point. The task manager shows that v.out.ogr is sleeping with
0% CPU.

I can reproduce this, both with your location and in spearfish. And at
first glance, it really does appear random. The only thing that I think I
noticed, was that it happens more often when the machine is busy with
something else. My first very wild guess would be something system
resources, but as I said, this is very wild.

Glynn, any hints as to where I should begin searching ?

Sometimes, I also get random "DBMI protocol errors". The only thing that
helps is to stop and restart the module, hoping that it will finish this
time. Quite annoying. I tested this with several different versions of
QGIS, Windows (XP, 2000) and with different datasets on different PCs:
always the same problem.

I only managed once to get a DBMI protocol error.

Moritz

26

Moritz Lennert wrote:

> 1. The DBF driver deadlocks randomly!
> Any GRASS module that needs to access the attribute table (DBF format)
> of a vector map is prone to this: E.g. I tried running v.out.ogr on a
> map with ca. 3000 points repeatedly. Out of ten runs, 2 or 3 deadlock at
> a random point. The task manager shows that v.out.ogr is sleeping with
> 0% CPU.

I can reproduce this, both with your location and in spearfish. And at
first glance, it really does appear random. The only thing that I think I
noticed, was that it happens more often when the machine is busy with
something else. My first very wild guess would be something system
resources, but as I said, this is very wild.

Glynn, any hints as to where I should begin searching ?

Run v.out.ogr under gdb; when it deadlocks, hit Ctrl-C, then type
"where" to get a backtrace (assuming that this works on Windows).

Or, if you can figure out how to attach gdb to a running process,
better still, as you can also get a backtrace for the DBF driver (on
Unix, you use "attach <pid>", but I don't know if that works on
Windows).

Also, "g.gisenv set=DEBUG=3" might help.

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

27

Hi
Em 21/05/2007, às 17:32, Paul Kelly escreveu:
8<-----------snip------------

IIUC (please correct me if I'm wrong) the QGIS GRASS is not true native Windows GRASS as it relies on Msys being installed to support Unix-isms in the GRASS code? We are currently working on removing many of these in order to get GRASS working reliably on native Windows without any Unix sub-system present.

I really should install QGIS+GRASS and see exactly what it does though. Can anybody clarify?

Yes it is relying on msys to the grass shell. QGIS grass is compiled natively in windows using msys / gcc.

8<------snip---------------

Regards

Tim Sutton (QGIS Dude :slight_smile:

28

Hi

Em 21/05/2007, às 13:15, Benjamin Ducke escreveu:

I think that we can actually make everybody happy here: it should be
possible to have a set of Win32 binaries that support tcl/tk forms (and
in the future wxPython) as well as run with current QGIS.
This way, we can provide several layers of GUI interaction to make the
transition for GIS newbies smooth:

1. QGIS with direct loading of file based geodata
2. the GRASS Toolbox providing a link to GRASS data and a simplified
modules interfaces
3. auto-generated forms on the command line (be they tcl/tk or wxPython)
4. pure command line
5. further tcl/tk and wxPython GUI tools for those that prefer them over
QGIS and its GRASS plugin stuff

... and all in a single Windows installer package!

The most important thing is to have a rock-solid set of binaries for
Win32. And I think we should focus on getting the command line stuff
with MSYS running perfectly first, then we can add GUI dependencies bit
by bit. And later get rid of shell dependencies. At any stage in the
process, there will be a fully usable GRASS on Windows. And everybody
can decide for themselves whether they want to have a package with
tcl/tk, wxpython, MSYS, NVIZ etc. or rather go with QGIS and Paraview.

Actually this s probably a good time to bring up a broader objective that myself and Norman Vine have bandied about on QGIS irc channel before today. What we really need is an interproject effort (not limited to just QGIS & GRASS) to build msys packages for developers. Think 'rpm' or 'deb' (actually probably closer to slackware tarball packages) but for msys environement. At the moment we have the rather inefficient and non-optimal situation where e.g. QGIS project builds gdal, proj , grass etc etc under msys, while in parallel other projects do the same thing. Surely it wil be ideal if each project puts forward their own msys packages built with best practice for that project in mind. This will prevent issues where I (being fairly GRASS inept) am building grass for QGIS and resultng in bug reports etc because I havent done an optimal job. If anyone has the wherewithal to coordinate and host such a project (perhaps even as a section under the msys packages list on sf) it would be a fantastic contribution.

Best regards

Tim Sutton (QGIS)

Let's just forget about Cygwin.

Benjamin

Paolo Cavallini wrote:

Michael Barton ha scritto:

It is a simple zip file and easy to install. Currently, it requires you to
separately install TclTk, and Mysys if you want to use scripts. It needs
testing, but is very actively being worked on. This is the direction for
GRASS for Windows.

Soory: whan you say this, what do you exactly mean? We are using the
qgis version, which has of course its limitations, but is very much
usable, and far easier for novices.
I think diversity is a byproduct of freedom, and we have several ways at
hand.
pc

--
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

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

29

Tim Sutton wrote:

Actually this s probably a good time to bring up a broader objective
that myself and Norman Vine have bandied about on QGIS irc channel
before today. What we really need is an interproject effort (not
limited to just QGIS & GRASS) to build msys packages for developers.
Think 'rpm' or 'deb' (actually probably closer to slackware tarball
packages) but for msys environement. At the moment we have the rather
inefficient and non-optimal situation where e.g. QGIS project builds
gdal, proj , grass etc etc under msys, while in parallel other
projects do the same thing. Surely it wil be ideal if each project
puts forward their own msys packages built with best practice for
that project in mind. This will prevent issues where I (being fairly
GRASS inept) am building grass for QGIS and resultng in bug reports
etc because I havent done an optimal job. If anyone has the
wherewithal to coordinate and host such a project (perhaps even as a
section under the msys packages list on sf) it would be a fantastic
contribution.

perhaps you could host it at SourceForge and call it ratfink.sf.net.
(or funk.sf.net, ...)

Hamish

30

Moritz Lennert wrote:

On Mon, May 21, 2007 13:58, Benjamin Ducke wrote:

1. The DBF driver deadlocks randomly!
Any GRASS module that needs to access the attribute table (DBF format)
of a vector map is prone to this: E.g. I tried running v.out.ogr on a
map with ca. 3000 points repeatedly. Out of ten runs, 2 or 3 deadlock at
a random point. The task manager shows that v.out.ogr is sleeping with
0% CPU.

I can reproduce this, both with your location and in spearfish. And at
first glance, it really does appear random. The only thing that I think I
noticed, was that it happens more often when the machine is busy with
something else. My first very wild guess would be something system
resources, but as I said, this is very wild.

Oh great, so I am not alone! I was seriously starting to doubt my karma
as nobody except myself seems to have hit this annoying bug while I am
getting frustrated hunting it down for weeks now.

The interesting thing is that this never happened to me on a Linux
system. Now at least I know that the problem is not my Windows setup and
can start firing up GDB ...

Glynn, any hints as to where I should begin searching ?

Sometimes, I also get random "DBMI protocol errors". The only thing that
helps is to stop and restart the module, hoping that it will finish this
time. Quite annoying. I tested this with several different versions of
QGIS, Windows (XP, 2000) and with different datasets on different PCs:
always the same problem.

I only managed once to get a DBMI protocol error.

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

31

Benjamin

Let's just forget about Cygwin.

Michael :

>> Cygwin is the old, stopgap method to get GRASS running in some way
>> under windows. However, it is difficult to install, especially on
>> lab machines and often conflicts with Byzantine Windows security
>> measures. I believe the Cygwin is being maintained, but not being
>> actively developed.

Glynn:

> There's nothing to "develop".

Paul:

Yes, just to re-iterate that point - I've been using GRASS on Cygwin
for years (not recently though) and it is stable and full-featured.
Have also introduced several non-Unix users to GRASS through Cygwin.
In my experience though if people are scared of Unix, they won't like
it. But it's a very viable option for using GRASS on Windows.

Cygwin is the only fully functional, stable, and mature version of GRASS
on Windows available today. That is, everything that works in a normal
UNIX version of GRASS works in Cygwin- it's a complete "port" (because
it isn't a port at all). It's ready to be used, now.

FWIW, in my introducing GRASS to new users I have learnt that it is
better to install an older stable version vs pushing a latest-greatest
development version: it's frustrating for me, but they don't miss much
new features which don't yet exist in the stable version. But trying
to explain that something is broken now, but it worked last week, so
wait two days and we'll recompile, ..., just doesn't cut it.
A year later, they are still using GRASS 5.7 as it is installed and it
works- and not very interested in an upgrade as it might disturb their
working solution.

ie the old solution isn't necessarily so bad, just because it is old.
Cygwin may not be the future of winGRASS, but it still has its place.
Giving a new non-Unixy user beta software does not have positive
outcomes. Icon from the desktop startup avoids most terminal prompt
exposure.

However, it is difficult to install,

I can't help with negotiations with afraid-of-the-unknown IT staff, but
the Cygwin 6.2.1 package should be much easier to install than previous
versions, so try again if you haven't in a while. It's nothing like a
grass_setup.exe, but it is much smoother than it was.

With their permission, I would like to add Huidae Cho's Cygwin install
instructions and Lorenzo's startup instructions into the add-ons SVN, so
we can generate updated PDF+HTML guides as needed, whenever we do a new
release.

Hamish

32

On 22/05/07 09:22, Hamish wrote:

Benjamin

Let's just forget about Cygwin.

Michael :

Cygwin is the old, stopgap method to get GRASS running in some way
under windows. However, it is difficult to install, especially on
lab machines and often conflicts with Byzantine Windows security
measures. I believe the Cygwin is being maintained, but not being
actively developed.

Glynn:

There's nothing to "develop".

Paul:

Yes, just to re-iterate that point - I've been using GRASS on Cygwin
for years (not recently though) and it is stable and full-featured.
Have also introduced several non-Unix users to GRASS through Cygwin.
In my experience though if people are scared of Unix, they won't like
it. But it's a very viable option for using GRASS on Windows.

Cygwin is the only fully functional, stable, and mature version of GRASS
on Windows available today. That is, everything that works in a normal
UNIX version of GRASS works in Cygwin- it's a complete "port" (because
it isn't a port at all). It's ready to be used, now.

I agree on that. The only inconvenience I have encountered is that the cygwin solution was significantly slower then a native GNU/Linux one.

Moritz

33

On 5/22/07 12:22 AM, "Hamish" <hamish_nospam@yahoo.com> wrote:

I can't help with negotiations with afraid-of-the-unknown IT staff, but
the Cygwin 6.2.1 package should be much easier to install than previous
versions, so try again if you haven't in a while. It's nothing like a
grass_setup.exe, but it is much smoother than it was.

I agree with your sentiment about making a useable, stable version availble
to people. GRASS under Cygwin is indeed a complete Linux version running
under Windows.

However, in addition to the problem of Lab IT managers (not insubstantial if
I want to use a university computer classroom to teach GIS), Cygwin seems to
run into repeated permissions issues under Windows. It is especially
difficult if it is on a machine that more than one person uses (i.e.,
multiple accounts). I've worked with very cooperative IT people who have yet
to be able to solve this sufficiently.

Another issue is that the installation is fairly easy for a single user
(though it remains complicated), but does not lend itself to installation on
a bunch of lab workstations. If Cygwin and GRASS could come as a single
*.exe file on a CD, it would be a LOT better for many users and lab
managers.

Finally, using GRASS under Cygwin, puts the user into an unfamiliar
environment. This is understandably confusing for many Windows users. GRASS
may work just fine, but it is working under Linux/Unix, which simply offers
a different user experience than stock Windows.

We definitely need to keep the Cygwin installation because it IS a
full-featured version of GRASS that is EXACTLY the same as the *nix
versions. However, there are a number of important reasons to place a high
priority on getting a Windows-native version out the door too.

Michael

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

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

34

My experiences would be along the same lines: GRASS + QGIS is far easier
to teach to people as you don't have the whole burden of learning Unix
coming down on them at the same time they are struggling with basic GIS
principles.

Also, GRASS + QGIS can be run from e.g. a USB drive: no administration
privileges necessary = no need to bother with IT staff.

Of course, this does not speak against also providing an up-to-date
Cygwin version, but we cannot use that as an excuse to not try and get a
fully working GRASS + QGIS package out of the door as soon as possible
-- I think.

Benjamin

Michael Barton wrote:

On 5/22/07 12:22 AM, "Hamish" <hamish_nospam@yahoo.com> wrote:

I can't help with negotiations with afraid-of-the-unknown IT staff, but
the Cygwin 6.2.1 package should be much easier to install than previous
versions, so try again if you haven't in a while. It's nothing like a
grass_setup.exe, but it is much smoother than it was.

I agree with your sentiment about making a useable, stable version availble
to people. GRASS under Cygwin is indeed a complete Linux version running
under Windows.

However, in addition to the problem of Lab IT managers (not insubstantial if
I want to use a university computer classroom to teach GIS), Cygwin seems to
run into repeated permissions issues under Windows. It is especially
difficult if it is on a machine that more than one person uses (i.e.,
multiple accounts). I've worked with very cooperative IT people who have yet
to be able to solve this sufficiently.

Another issue is that the installation is fairly easy for a single user
(though it remains complicated), but does not lend itself to installation on
a bunch of lab workstations. If Cygwin and GRASS could come as a single
*.exe file on a CD, it would be a LOT better for many users and lab
managers.

Finally, using GRASS under Cygwin, puts the user into an unfamiliar
environment. This is understandably confusing for many Windows users. GRASS
may work just fine, but it is working under Linux/Unix, which simply offers
a different user experience than stock Windows.

We definitely need to keep the Cygwin installation because it IS a
full-featured version of GRASS that is EXACTLY the same as the *nix
versions. However, there are a number of important reasons to place a high
priority on getting a Windows-native version out the door too.

Michael

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

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

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

--
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

35

On Tue, May 22, 2007 05:05, Glynn Clements wrote:

Moritz Lennert wrote:

> 1. The DBF driver deadlocks randomly!
> Any GRASS module that needs to access the attribute table (DBF format)
> of a vector map is prone to this: E.g. I tried running v.out.ogr on a
> map with ca. 3000 points repeatedly. Out of ten runs, 2 or 3 deadlock
at
> a random point. The task manager shows that v.out.ogr is sleeping with
> 0% CPU.

I can reproduce this, both with your location and in spearfish. And at
first glance, it really does appear random. The only thing that I think
I
noticed, was that it happens more often when the machine is busy with
something else. My first very wild guess would be something system
resources, but as I said, this is very wild.

Glynn, any hints as to where I should begin searching ?

Run v.out.ogr under gdb; when it deadlocks, hit Ctrl-C, then type
"where" to get a backtrace (assuming that this works on Windows).

It does. Backtrace attached. However, I am not sure that this backtrace is
very useful (many ??). Looking for an explanation, I found this:

http://www.cygwin.com/ml/cygwin/2006-09/msg00409.html

But maybe I have to compile with some debug option of gcc ? (gcc -g ?)

(
If others want to try, these are the commands I used:

gdb (from MinGW)

file v.out.ogr
run in=points dsn=c:/testing olayer=points type=point
Ctrl-C when it deadlocks
set logging on
where
quit

)

Or, if you can figure out how to attach gdb to a running process,
better still, as you can also get a backtrace for the DBF driver (on
Unix, you use "attach <pid>", but I don't know if that works on
Windows).

It's possible:
- In the Windows Task-Manager (Ctrl-Alt-Delete) go to View->Select Columns
and add PID.
- run v.out.ogr command
- when it deadlocks, run gdb in another cmd.exe window
- use 'attach PID'

backtrace attached. Same ?? problem.

Also, "g.gisenv set=DEBUG=3" might help.

I didn't have the feeling that it did, but I have attached an excerpt with
the last lines.

Moritz

(attachments)

gdb_v_out_ogr_winGRASS.txt (2.06 KB)
gdb_dbf_winGRASS.txt (786 Bytes)
gisenv_debug_v_out_ogr_wingrass.txt (3.1 KB)

36

Moritz Lennert wrote:

>> > 1. The DBF driver deadlocks randomly!
>> > Any GRASS module that needs to access the attribute table (DBF format)
>> > of a vector map is prone to this: E.g. I tried running v.out.ogr on a
>> > map with ca. 3000 points repeatedly. Out of ten runs, 2 or 3 deadlock
>> at
>> > a random point. The task manager shows that v.out.ogr is sleeping with
>> > 0% CPU.
>>
>> I can reproduce this, both with your location and in spearfish. And at
>> first glance, it really does appear random. The only thing that I think
>> I
>> noticed, was that it happens more often when the machine is busy with
>> something else. My first very wild guess would be something system
>> resources, but as I said, this is very wild.
>>
>> Glynn, any hints as to where I should begin searching ?
>
> Run v.out.ogr under gdb; when it deadlocks, hit Ctrl-C, then type
> "where" to get a backtrace (assuming that this works on Windows).

It does. Backtrace attached. However, I am not sure that this backtrace is
very useful (many ??). Looking for an explanation, I found this:

http://www.cygwin.com/ml/cygwin/2006-09/msg00409.html

But maybe I have to compile with some debug option of gcc ? (gcc -g ?)

Are you using Cygwin's gdb? It doesn't work on native Windows
binaries. There is a native (MinGW) gdb at:

  http://prdownloads.sf.net/mingw/gdb-5.2.1-1.exe?download

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

37

On 25/05/07 02:24, Glynn Clements wrote:

Moritz Lennert wrote:

1. The DBF driver deadlocks randomly!
Any GRASS module that needs to access the attribute table (DBF format)
of a vector map is prone to this: E.g. I tried running v.out.ogr on a
map with ca. 3000 points repeatedly. Out of ten runs, 2 or 3 deadlock

at

a random point. The task manager shows that v.out.ogr is sleeping with
0% CPU.

I can reproduce this, both with your location and in spearfish. And at
first glance, it really does appear random. The only thing that I think
I
noticed, was that it happens more often when the machine is busy with
something else. My first very wild guess would be something system
resources, but as I said, this is very wild.

Glynn, any hints as to where I should begin searching ?

Run v.out.ogr under gdb; when it deadlocks, hit Ctrl-C, then type
"where" to get a backtrace (assuming that this works on Windows).

It does. Backtrace attached. However, I am not sure that this backtrace is
very useful (many ??). Looking for an explanation, I found this:

http://www.cygwin.com/ml/cygwin/2006-09/msg00409.html

But maybe I have to compile with some debug option of gcc ? (gcc -g ?)

Are you using Cygwin's gdb? It doesn't work on native Windows
binaries. There is a native (MinGW) gdb at:

  http://prdownloads.sf.net/mingw/gdb-5.2.1-1.exe?download

I use MinGW's gdb, but a more recent version:

http://prdownloads.sf.net/mingw/gdb-6.3-1.exe?download

Moritz