Cygwin Subprocesses on XEmacs

Cygwin Subprocesses on XEmacs

[Vin Shelton]

I spent some time debugging M-x shell in XEmacs on 32-bit Cygwin.
Here's what I found out.

In the child after fork() but before exec(), the setsid() call in
disconnect_controlling_terminal() is causing the subprocess not to
function after it gets spawned.

Here is a patch which works around the problem, enabling M-x shell to
work for bash and zsh (at least):

diff -r 00f2705e2cb3 src/sysdep.c
--- a/src/sysdep.c Mon Jan 26 08:53:07 2015 -0500
+++ b/src/sysdep.c Tue Jan 27 22:15:16 2015 -0500
@@ -1319,7 +1319,7 @@
 void
 disconnect_controlling_terminal (void)
 {
-#  ifdef HAVE_SETSID
+#  if defined(HAVE_SETSID) && !defined(CYGWIN)
   /* Controlling terminals are attached to a session.
      Create a new session for us; it will have no controlling
      terminal.  This also, of course, puts us in our own


HOWEVER - I don't understand why this should be necessary.


I here reproduce all of disconnect_controlling_terminal() for your
reading pleasure.

void
disconnect_controlling_terminal (void)
{
#  if defined(HAVE_SETSID) && !defined(CYGWIN)
  /* Controlling terminals are attached to a session.
     Create a new session for us; it will have no controlling
     terminal.  This also, of course, puts us in our own
     process group. */
  setsid ();
#  else
  /* Put us in our own process group. */
  EMACS_SEPARATE_PROCESS_GROUP ();
#    if defined (TIOCNOTTY)
  /* This is the older way of disconnecting the controlling
     terminal, on 4.3 BSD.  We must open /dev/tty; using
     filedesc 0 is not sufficient because it could be
     something else (e.g. our stdin was redirected to
     another terminal).
     */
  {
    int j = open ("/dev/tty", O_RDWR, 0);
    ioctl (j, TIOCNOTTY, 0);
    close (j);
  }
#    endif /* TIOCNOTTY */
  /*
     On systems without TIOCNOTTY and without
     setsid(), we don't need to do anything more to
     disconnect our controlling terminal.  Here is
     what the man page for termio(7) from a SYSV 3.2
     system says:

     "The first terminal file opened by the process group leader
     of a terminal file not already associated with a process
     group becomes the control terminal for that process group.
     The control terminal plays a special role in handling quit
     and interrupt signals, as discussed below.  The control
     terminal is inherited by a child process during a fork(2).
     A process can break this association by changing its process
     group using setpgrp(2)."

     */
#  endif /* not HAVE_SETSID */
}


Since Cygwin doesn't seem to have TIOCNOTTY, commenting out the
setsid() call reduces disconnect_controlling_terminal to:

void
disconnect_controlling_terminal (void)
{
# 1330 "sysdep.c"
  setpgid (0, 0);
# 1362 "sysdep.c"
}

Incidentally, that setpgid() call causes bash to complain at startup:

bash: cannot set terminal process group (-1): Inappropriate ioctl for device
bash: no job control in this shell

Thanks for any insight you can offer.

  - Vin

Re: Cygwin Subprocesses on XEmacs

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 2199 bytes --]

Hi Vin,


first of all, I haven't looked into the affected piece of code in Cygwin
for a long time, and it was never my domain, so bear with me.


On Jan 27 23:05, Vin Shelton wrote:
> I spent some time debugging M-x shell in XEmacs on 32-bit Cygwin.
> Here's what I found out.
> 
> In the child after fork() but before exec(), the setsid() call in
> disconnect_controlling_terminal() is causing the subprocess not to
> function after it gets spawned.

Can you define "not function" a bit more detailed?  Does no process work
at all, or do only processes requiring a tty not work?  For instance,
does something like an "echo foo > bar" still work?

> Here is a patch which works around the problem, enabling M-x shell to
> work for bash and zsh (at least):
> 
> diff -r 00f2705e2cb3 src/sysdep.c
> --- a/src/sysdep.c Mon Jan 26 08:53:07 2015 -0500
> +++ b/src/sysdep.c Tue Jan 27 22:15:16 2015 -0500
> @@ -1319,7 +1319,7 @@
>  void
>  disconnect_controlling_terminal (void)
>  {
> -#  ifdef HAVE_SETSID
> +#  if defined(HAVE_SETSID) && !defined(CYGWIN)
>    /* Controlling terminals are attached to a session.
>       Create a new session for us; it will have no controlling
>       terminal.  This also, of course, puts us in our own
> 
> 
> HOWEVER - I don't understand why this should be necessary.
> [...]
> Since Cygwin doesn't seem to have TIOCNOTTY, commenting out the
> setsid() call reduces disconnect_controlling_terminal to:
> 
> void
> disconnect_controlling_terminal (void)
> {
> # 1330 "sysdep.c"
>   setpgid (0, 0);
> # 1362 "sysdep.c"
> }
> 
> Incidentally, that setpgid() call causes bash to complain at startup:
> 
> bash: cannot set terminal process group (-1): Inappropriate ioctl for device
> bash: no job control in this shell
> 
> Thanks for any insight you can offer.

Hmm, not off the top of my head.  Is there a chance that you could
provide a simple, self contained testcase to reproduce the setsid
behaviour?  I think I have to debug that.


Thanks,
Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: Cygwin Subprocesses on XEmacs

[Vin Shelton]

Hi, Corinna et al,

On Wed, Jan 28, 2015 at 4:53 AM, Corinna Vinschen wrote:
> On Jan 27 23:05, Vin Shelton wrote:
>> I spent some time debugging M-x shell in XEmacs on 32-bit Cygwin.
>> Here's what I found out.
>>
>> In the child after fork() but before exec(), the setsid() call in
>> disconnect_controlling_terminal() is causing the subprocess not to
>> function after it gets spawned.
>
> Can you define "not function" a bit more detailed?  Does no process work
> at all, or do only processes requiring a tty not work?  For instance,
> does something like an "echo foo > bar" still work?

M-x shell is specifically designed to spawn an interactive process
like a shell.  The bash subprocess starts, but it accepts no input.
Here is the output of ps for that process:

S    1740     252    1740        268  pty1    1003 08:10:54 /usr/bin/bash

I think it's only commands requiring a tty, but that's the whole point
of M-x shell mode.  There is a separate command - M-x shell-command -
which is designed to run and capture the output of individual commands
like "ls" or "echo".  That works fine.

BTW, if I try to spawn gdb as a shell, the behavior is similar, but
this time the process looks like this:

     3328    3248    3328       3408  pty2    1003 08:15:18
/usr/bin/gdb <defunct>

HTH.

>>
>> Thanks for any insight you can offer.
>
> Hmm, not off the top of my head.  Is there a chance that you could
> provide a simple, self contained testcase to reproduce the setsid
> behaviour?  I think I have to debug that.

You mean a simpler test case than XEmacs?  That seems like a low bar.  :-)

I'll try.  Meanwhile, I've been looking at the emacs code (which in
this case is simpler) to see if I can figure out how it is that M-x
shell works there.

Thank you!

  - Vin

Re: Cygwin Subprocesses on XEmacs

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 2276 bytes --]

On Jan 28 08:20, Vin Shelton wrote:
> Hi, Corinna et al,
> 
> On Wed, Jan 28, 2015 at 4:53 AM, Corinna Vinschen wrote:
> > On Jan 27 23:05, Vin Shelton wrote:
> >> I spent some time debugging M-x shell in XEmacs on 32-bit Cygwin.
> >> Here's what I found out.
> >>
> >> In the child after fork() but before exec(), the setsid() call in
> >> disconnect_controlling_terminal() is causing the subprocess not to
> >> function after it gets spawned.
> >
> > Can you define "not function" a bit more detailed?  Does no process work
> > at all, or do only processes requiring a tty not work?  For instance,
> > does something like an "echo foo > bar" still work?
> 
> M-x shell is specifically designed to spawn an interactive process
> like a shell.  The bash subprocess starts, but it accepts no input.
> Here is the output of ps for that process:
> 
> S    1740     252    1740        268  pty1    1003 08:10:54 /usr/bin/bash
> 
> I think it's only commands requiring a tty, but that's the whole point
> of M-x shell mode.  There is a separate command - M-x shell-command -
> which is designed to run and capture the output of individual commands
> like "ls" or "echo".  That works fine.
> 
> BTW, if I try to spawn gdb as a shell, the behavior is similar, but
> this time the process looks like this:
> 
>      3328    3248    3328       3408  pty2    1003 08:15:18
> /usr/bin/gdb <defunct>
> 
> HTH.
> 
> >>
> >> Thanks for any insight you can offer.
> >
> > Hmm, not off the top of my head.  Is there a chance that you could
> > provide a simple, self contained testcase to reproduce the setsid
> > behaviour?  I think I have to debug that.
> 
> You mean a simpler test case than XEmacs?  That seems like a low bar.  :-)

LOL.

Btw., a testcase which avoids to fork would be nice.  It's much easier
to debug due to GDBs inability to follow fork on Cygwin :(

> I'll try.  Meanwhile, I've been looking at the emacs code (which in
> this case is simpler) to see if I can figure out how it is that M-x
> shell works there.

Good idea.  This might give us a clue.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: Cygwin Subprocesses on XEmacs

[Vin Shelton]

Dear Corinna, et al -

On Wed, Jan 28, 2015 at 8:58 AM, Corinna Vinschen wrote:
> On Jan 28 08:20, Vin Shelton wrote:
>> On Wed, Jan 28, 2015 at 4:53 AM, Corinna Vinschen wrote:
>> > On Jan 27 23:05, Vin Shelton wrote:
>> >> I spent some time debugging M-x shell in XEmacs on 32-bit Cygwin.
>> >> Here's what I found out.
>> >>
>> >> In the child after fork() but before exec(), the setsid() call in
>> >> disconnect_controlling_terminal() is causing the subprocess not to
>> >> function after it gets spawned.
>> >
>> > Can you define "not function" a bit more detailed?  Does no process work
>> > at all, or do only processes requiring a tty not work?  For instance,
>> > does something like an "echo foo > bar" still work?
>>
>> M-x shell is specifically designed to spawn an interactive process
>> like a shell.  The bash subprocess starts, but it accepts no input.
>> Here is the output of ps for that process:
>>
>> S    1740     252    1740        268  pty1    1003 08:10:54 /usr/bin/bash
>>
>> I think it's only commands requiring a tty, but that's the whole point
>> of M-x shell mode.  There is a separate command - M-x shell-command -
>> which is designed to run and capture the output of individual commands
>> like "ls" or "echo".  That works fine.
>>
>> BTW, if I try to spawn gdb as a shell, the behavior is similar, but
>> this time the process looks like this:
>>
>>      3328    3248    3328       3408  pty2    1003 08:15:18
>> /usr/bin/gdb <defunct>
>>
>> HTH.
>>
>> >>
>> >> Thanks for any insight you can offer.
>> >
>> > Hmm, not off the top of my head.  Is there a chance that you could
>> > provide a simple, self contained testcase to reproduce the setsid
>> > behaviour?  I think I have to debug that.
>>
>> You mean a simpler test case than XEmacs?  That seems like a low bar.  :-)
>
> LOL.

After thinking about this for awhile, it dawned on me that the problem
is not with setsid() per se, but rather with the sequence of events
_following_ the setsid() call.  That is, setsid() causes some of the
ensuing ioctl() (or similar) calls that set up the pty to fail.

I think I have verified this behavior - I restored the old sysdep.c
module and moved the disconnect_controlling_terminal() call [which
calls setsid()] from right after the fork() to just before the exec()
call and M-x shell works on Cygwin as it always has on linux.

I will endeavor to create a STC for Cygwin that includes all the code
involved in setting up the terminal so we can experiment with moving
the setsid() call between the beginning and the end of the function.

  - Vin

Re: Cygwin Subprocesses on XEmacs

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 2303 bytes --]

Hi Vin,

On Jan 28 22:32, Vin Shelton wrote:
> Dear Corinna, et al -
> 
> On Wed, Jan 28, 2015 at 8:58 AM, Corinna Vinschen wrote:
> > On Jan 28 08:20, Vin Shelton wrote:
> >> On Wed, Jan 28, 2015 at 4:53 AM, Corinna Vinschen wrote:
> >> > On Jan 27 23:05, Vin Shelton wrote:
> >> >> I spent some time debugging M-x shell in XEmacs on 32-bit Cygwin.
> >> >> Here's what I found out.
> >> >>
> >> >> In the child after fork() but before exec(), the setsid() call in
> >> >> disconnect_controlling_terminal() is causing the subprocess not to
> >> >> function after it gets spawned.
> >> >
> >> > Can you define "not function" a bit more detailed?  Does no process work
> >> > at all, or do only processes requiring a tty not work?  For instance,
> >> > does something like an "echo foo > bar" still work?
> >> [...]
> >> >> Thanks for any insight you can offer.
> >> >
> >> > Hmm, not off the top of my head.  Is there a chance that you could
> >> > provide a simple, self contained testcase to reproduce the setsid
> >> > behaviour?  I think I have to debug that.
> >>
> >> You mean a simpler test case than XEmacs?  That seems like a low bar.  :-)
> >
> > LOL.
> 
> After thinking about this for awhile, it dawned on me that the problem
> is not with setsid() per se, but rather with the sequence of events
> _following_ the setsid() call.  That is, setsid() causes some of the
> ensuing ioctl() (or similar) calls that set up the pty to fail.
> 
> I think I have verified this behavior - I restored the old sysdep.c
> module and moved the disconnect_controlling_terminal() call [which
> calls setsid()] from right after the fork() to just before the exec()
> call and M-x shell works on Cygwin as it always has on linux.

Good news!  So the XEmacs code is in a state now that Volker can
start creating a Cygwin package?

> I will endeavor to create a STC for Cygwin that includes all the code
> involved in setting up the terminal so we can experiment with moving
> the setsid() call between the beginning and the end of the function.

Ok, thanks.  Hopefully we can find the snag in Cygwin.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: Cygwin Subprocesses on XEmacs

[Vin Shelton]

On Thu, Jan 29, 2015 at 4:39 AM, Corinna Vinschen wrote:
> On Jan 28 22:32, Vin Shelton wrote:
>> I think I have verified this behavior - I restored the old sysdep.c
>> module and moved the disconnect_controlling_terminal() call [which
>> calls setsid()] from right after the fork() to just before the exec()
>> call and M-x shell works on Cygwin as it always has on linux.
>
> Good news!  So the XEmacs code is in a state now that Volker can
> start creating a Cygwin package?

Yes, the 21.4 code in the hg repository builds and runs on Cygwin.

Regards,
  Vin

Re: Cygwin Subprocesses on XEmacs

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 804 bytes --]

On Jan 29 06:49, Vin Shelton wrote:
> On Thu, Jan 29, 2015 at 4:39 AM, Corinna Vinschen wrote:
> > On Jan 28 22:32, Vin Shelton wrote:
> >> I think I have verified this behavior - I restored the old sysdep.c
> >> module and moved the disconnect_controlling_terminal() call [which
> >> calls setsid()] from right after the fork() to just before the exec()
> >> call and M-x shell works on Cygwin as it always has on linux.
> >
> > Good news!  So the XEmacs code is in a state now that Volker can
> > start creating a Cygwin package?
> 
> Yes, the 21.4 code in the hg repository builds and runs on Cygwin.

Super!


Thanks a lot,
Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: Cygwin Subprocesses on XEmacs

[Dr. Volker Zell]

>>>>> Vin Shelton writes:

    > On Thu, Jan 29, 2015 at 4:39 AM, Corinna Vinschen wrote:
    >> On Jan 28 22:32, Vin Shelton wrote:
    >>> I think I have verified this behavior - I restored the old sysdep.c
    >>> module and moved the disconnect_controlling_terminal() call [which
    >>> calls setsid()] from right after the fork() to just before the exec()
    >>> call and M-x shell works on Cygwin as it always has on linux.
    >> 
    >> Good news!  So the XEmacs code is in a state now that Volker can
    >> start creating a Cygwin package?

    > Yes, the 21.4 code in the hg repository builds and runs on Cygwin.

I downloaded the latest version 21.4.23 and tried to build it, but I consistently get:

gcc -c -ggdb -O2 -pipe -Wimplicit-function-declaration -fdebug-prefix-map=/cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/build=/usr/src/debug/xemacs-21.4.22-2 -fdebug-prefix-map=/cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/src/xemacs-21.4.22=/usr/src/debug/xemacs-21.4.22-2  -Demacs -I. -DHAVE_CONFIG_H -Wno-sign-compare -fno-caller-saves dump-id.c
gcc -ggdb -O2 -pipe -Wimplicit-function-declaration -fdebug-prefix-map=/cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/build=/usr/src/debug/xemacs-21.4.22-2 -fdebug-prefix-map=/cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/src/xemacs-21.4.22=/usr/src/debug/xemacs-21.4.22-2     -o xemacs  abbrev.o alloc.o blocktype.o buffer.o bytecode.o callint.o callproc.o casefiddle.o casetab.o chartab.o cmdloop.o cmds.o console.o console-stream.o data.o device.o dired.o doc.o doprnt.o dynarr.o editfns.o elhash.o emacs.o eval.o events.o filelock.o ntplay.o dumper.o scrollbar-msw.o menubar-msw.o toolbar-msw.o dialog-msw.o console-msw.o device-msw.o event-msw.o frame-msw.o objects-msw.o select-msw.o redisplay-msw.o glyphs-msw.o gui-msw.o balloon_help.o balloon-x.o dragdrop.o eldap.o postgresql.o dgif_lib.o gif_io.o menubar.o scrollbar.o dialog.o toolbar.o menubar-x.o scrollbar-x.o dialog-x.o toolbar-x.o gui-x.o mule.o mule-ccl.o mule-charset.o file-coding.o input-method-xlib.o realpath.o getloadavg.o inline.o nas.o console-tty.o device-tty.o event-tty.o frame-tty.o objects-tty.o redisplay-tty.o cm.o terminfo.o event-unixoid.o database.o process-unix.o event-stream.o extents.o faces.o fileio.o  filemode.o floatfns.o fns.o font-lock.o frame.o general.o glyphs.o glyphs-eimage.o glyphs-widget.o gui.o gutter.o  hash.o imgproc.o indent.o insdel.o intl.o keymap.o  line-number.o lread.o lstream.o macros.o marker.o md5.o minibuf.o objects.o opaque.o print.o process.o profile.o rangetab.o redisplay.o redisplay-output.o regex.o search.o select.o  signal.o sound.o specifier.o strftime.o symbols.o syntax.o sysdep.o undo.o console-x.o device-x.o event-Xt.o frame-x.o glyphs-x.o objects-x.o redisplay-x.o select-x.o xgccache.o widget.o window.o win32.o xemacs_res.o lastfile.o gmalloc.o vm-limit.o  EmacsFrame.o EmacsShell.o TopLevelEmacsShell.o TransientEmacsShell.o EmacsManager.o  offix.o dump-id.o ../lwlib/liblw.a  -laudio -lXaw3d -lXaw3d -ltiff -lpng -ljpeg -lz -lcompface -lXpm -lXmu -lXt -lXext -lX11 -lSM -lICE -ldb -lncurses -lintl -lpq -lldap -llber -lwinmm -lshell32 -lgdi32 -luser32 -lcomdlg32 -lcomctl32 -lkernel32 -lwinspool 
collect2: error: ld terminated with signal 11 [Segmentation fault], core dumped
GNUmakefile:159: recipe for target 'xemacs' failed
make[1]: *** [xemacs] Error 1
make[1]: Leaving directory '/cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/build/src'
GNUmakefile:123: recipe for target 'src' failed
make: *** [src] Error 2
^[[1;31m*** ERROR:^[[0;0m make failed


After the ld core dump, when I delete the corrupted xemacs.exe from
/cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/build/src manually
and restart the build with make from the
/cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/build directory
again, the build actually succeeds and ld doesn't core dump
anymore. Additionally I had to use an older version of texinfo (namely
version 4.13) otherwise the build breaks when generating the .info files
(I got the information to use an older version from Vin Shelton).

I then installed everything and with my current setup xemacs crashed as
soon as font-locking is involved. The current 32 bit xemacs-21.4.22
version works fine with this setup. After googling around I found a
workaround by setting (setq progress-feedback-use-echo-area t) in my
.emacs.

So, the good news finally after 6 years !!! it seems I have a working
xemacs on 32 bit which runs on cygwin 1.7.x. Of course I will need to do
more testing.

The bad news, an automatic build via cygport is currently not possible because:

1. cygport's compile stage bails out after the ld core dump
2. the current xemacs version needs an older version of texinfo (4.13)
   than we have currently in the distribution (5.2-3)

Question: How shall I proceed ?

By the way, I'm off for a week.

    > Regards,
    >   Vin

Ciao
  Volker
  

Re: Cygwin Subprocesses on XEmacs

[Vin Shelton]

Volker -
On Fri, Jan 30, 2015 at 10:51 AM, Dr. Volker Zell wrote:
> I downloaded the latest version 21.4.23 and tried to build it, but I consistently get:
>
> gcc -c -ggdb -O2 -pipe -Wimplicit-function-declaration -fdebug-prefix-map=/cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/build=/usr/src/debug/xemacs-21.4.22-2 -fdebug-prefix-map=/cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/src/xemacs-21.4.22=/usr/src/debug/xemacs-21.4.22-2  -Demacs -I. -DHAVE_CONFIG_H -Wno-sign-compare -fno-caller-saves dump-id.c
> gcc -ggdb -O2 -pipe -Wimplicit-function-declaration -fdebug-prefix-map=/cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/build=/usr/src/debug/xemacs-21.4.22-2 -fdebug-prefix-map=/cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/src/xemacs-21.4.22=/usr/src/debug/xemacs-21.4.22-2     -o xemacs  abbrev.o alloc.o blocktype.o buffer.o bytecode.o callint.o callproc.o casefiddle.o casetab.o chartab.o cmdloop.o cmds.o console.o console-stream.o data.o device.o dired.o doc.o doprnt.o dynarr.o editfns.o elhash.o emacs.o eval.o events.o filelock.o ntplay.o dumper.o scrollbar-msw.o menubar-msw.o toolbar-msw.o dialog-msw.o console-msw.o device-msw.o event-msw.o frame-msw.o objects-msw.o select-msw.o redisplay-msw.o glyphs-msw.o gui-msw.o balloon_help.o balloon-x.o dragdrop.o eldap.o postgresql.o dgif_lib.o gif_io.o menubar.o scrollbar.o dialog.o toolbar.o menubar-x.o scrollbar-x.o dialog-x.o toolbar-x.o gui-x.o mule.o mule-ccl.o mule-charset.o file-coding.o input-method-xlib.o realpath.o getloadavg.o inline.o nas.o console-tty.o device-tty.o event-tty.o frame-tty.o objects-tty.o redisplay-tty.o cm.o terminfo.o event-unixoid.o database.o process-unix.o event-stream.o extents.o faces.o fileio.o  filemode.o floatfns.o fns.o font-lock.o frame.o general.o glyphs.o glyphs-eimage.o glyphs-widget.o gui.o gutter.o  hash.o imgproc.o indent.o insdel.o intl.o keymap.o  line-number.o lread.o lstream.o macros.o marker.o md5.o minibuf.o objects.o opaque.o print.o process.o profile.o rangetab.o redisplay.o redisplay-output.o regex.o search.o select.o  signal.o sound.o specifier.o strftime.o symbols.o syntax.o sysdep.o undo.o console-x.o device-x.o event-Xt.o frame-x.o glyphs-x.o objects-x.o redisplay-x.o select-x.o xgccache.o widget.o window.o win32.o xemacs_res.o lastfile.o gmalloc.o vm-limit.o  EmacsFrame.o EmacsShell.o TopLevelEmacsShell.o TransientEmacsShell.o EmacsManager.o  offix.o dump-id.o ../lwlib/liblw.a  -laudio -lXaw3d -lXaw3d -ltiff -lpng -ljpeg -lz -lcompface -lXpm -lXmu -lXt -lXext -lX11 -lSM -lICE -ldb -lncurses -lintl -lpq -lldap -llber -lwinmm -lshell32 -lgdi32 -luser32 -lcomdlg32 -lcomctl32 -lkernel32 -lwinspool
> collect2: error: ld terminated with signal 11 [Segmentation fault], core dumped
> GNUmakefile:159: recipe for target 'xemacs' failed
> make[1]: *** [xemacs] Error 1
> make[1]: Leaving directory '/cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/build/src'
> GNUmakefile:123: recipe for target 'src' failed
> make: *** [src] Error 2
>  [1;31m*** ERROR: [0;0m make failed
>
>
> After the ld core dump, when I delete the corrupted xemacs.exe from
> /cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/build/src manually
> and restart the build with make from the
> /cygdrive/d/misc/src/release/xemacs-21.4.22-2.i686/build directory
> again, the build actually succeeds and ld doesn't core dump
> anymore.

I don't see this segfault.  I am running the default version of gcc,
and I assume you are, too.  Perhaps you need to rebaseall?

Your build path is "...xemacs-21.4.22..." are you sure you're using
21.4.23 sources?

> Additionally I had to use an older version of texinfo (namely
> version 4.13) otherwise the build breaks when generating the .info files
> (I got the information to use an older version from Vin Shelton).

Yes, the texinfo incompatibilities is one reason I want to EOL 21.4.
An alternative approach for Cygwin would be to patch the .texi sources
to work with newer texinfos.

>
> I then installed everything and with my current setup xemacs crashed as
> soon as font-locking is involved. The current 32 bit xemacs-21.4.22
> version works fine with this setup. After googling around I found a
> workaround by setting (setq progress-feedback-use-echo-area t) in my
> .emacs.

This error should be fixed in 21.4.23, there's a new
configure.in/configure designed to prevent this.  Again - are you sure
you're using 21.4.23?

> So, the good news finally after 6 years !!! it seems I have a working
> xemacs on 32 bit which runs on cygwin 1.7.x. Of course I will need to do
> more testing.
>
> The bad news, an automatic build via cygport is currently not possible because:
>
> 1. cygport's compile stage bails out after the ld core dump
> 2. the current xemacs version needs an older version of texinfo (4.13)
>    than we have currently in the distribution (5.2-3)
>
> Question: How shall I proceed ?


  - Vin

Re: Cygwin Subprocesses on XEmacs

[Dr. Volker Zell]

>>>>> Vin Shelton writes:

    > I don't see this segfault.  I am running the default version of gcc,
    > and I assume you are, too.  Perhaps you need to rebaseall?

I'm using the latest gcc-4.9.2
    
    > Your build path is "...xemacs-21.4.22..." are you sure you're using
    > 21.4.23 sources?

Yes...I copied from the wrong log file (that was the latest build from
the hg repository I did before you released 21.4.23). But in the latest version I get the exact error.
    

    >> 
    >> I then installed everything and with my current setup xemacs crashed as
    >> soon as font-locking is involved. The current 32 bit xemacs-21.4.22
    >> version works fine with this setup. After googling around I found a
    >> workaround by setting (setq progress-feedback-use-echo-area t) in my
    >> .emacs.

    > This error should be fixed in 21.4.23, there's a new
    > configure.in/configure designed to prevent this.  Again - are you sure
    > you're using 21.4.23?

Yes...my current xemacs just spits out "XEmacs 21.4 (patch 23) "Moral Majority"....when using M-X: emacs-version
    
    >   - Vin

Ciao
  Volker