On 06/11/13 09:58, Eli Zaretskii wrote:
Can you find out (by looking at the glib sources) when and why would
g_spawn_close_pid call 'abort'? It might give us some clues.
On POSIX platforms, g_spawn_close_pid does nothing.
So apparently glib is compiled for Windows (i.e.,
glib/gspawn.c is not being compiled, but glib/gspawn-win32.c
is being compiled instead.
The Emacs code that tickles gnulib is written this way:
#if defined HAVE_GLIB && !defined WINDOWSNT
/* Tickle glib's child-handling code. Ask glib to wait for Emacs itself;
this should always fail, but is enough to initialize glib's
private SIGCHLD handler. */
g_source_unref (g_child_watch_source_new (getpid ()));
#endif
I did notice one problem: the code previously invoked
g_child_watch_source_new (0), which is not safe if Emacs
has already forked -- perhaps Cygwin was doing that?
So I changed it to g_child_watch_source_new (getpid ())
in trunk bzr 112929.
Another thought is that there may be a mismatch between
glib builds. Since WINDOWSNT is not defined for Cygwin builds,
a Cygwin Emacs will call g_child_watch_source_new. My reading of
the bleeding-edge glib source code is that a Cygwin glib should call
waitpid and mess with the SIGCHLD handler, just as a
POSIX glib would, so the above Emacs code is correct.
But if you're building under Cygwin and linking with
a mingw glib, the above code may well run into problems.
Is this a possibility that we should worry about?
2.32.1-not-win32.patch