Hi,
firstly -- thanks a lot for the efforts for straightening the matters.
I'm having a busy time right now, but I will try to apply your
solution ASAP, and so I need you to know how much I appreciate it!


> > > I guess you didn't configure without threads on GNU/Linux, did you?
> > > If not, I suggest to try that, my impression is that Guile without
> > > threads is not used too much on Posix platforms.
> >
> > Hydra, a continuous integration system, runs Guile's "make check" with
> > threads disabled on several POSIX platforms, so there's no need for
> > Panicz to do this test.
>
> Sorry, I disagree.  "make check" is not the issue here: Guile passes
> it on my machine with flying colors (see my reports back then).  And
> yet a simple program shown by Panicz aborts due to "stack overflow".
> I was suggesting to configure Guile on GNU/Linux without threads and
> run that same program: perhaps it will also fail.
>

So I eventually tried that (after having set up a virtual box especially
for that purpose), and everything went smoothly -- the "hello" message
was displayed without any complaints, despite the lack of threads.

In the meantime I've been still trying to build guile+bdw-gc with
thread support, and to spot the exact place which causes the error
message to pop out, but it's terribly slow (all the components of
libguile and guile.exe get rebuilt from scratch, in spite of the fact
that the error occurs at the guile-procedures.texi generation stage),
and I've been just placing some output messages here and there
throughout procedures in libgc/win32_threads.c (I wonder if there's
any way to configure the program, whether it be libgc or guile,
 so that it would print the C backtrace when the popup appears)

Best regards,
M.