bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#14569: 24.3.50; bootstrap fails on Cygwin


From: Paul Eggert
Subject: bug#14569: 24.3.50; bootstrap fails on Cygwin
Date: Tue, 11 Jun 2013 11:50:37 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130514 Thunderbird/17.0.6

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?





reply via email to

[Prev in Thread] Current Thread [Next in Thread]