Subject: bug#14569: 24.3.50; bootstrap fails on Cygwin

From: Paul Eggert <[email-masked]>
Date: Tue, 11 Jun 2013 11:50:37 -0700

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?