Re: New emacs maintainer for cygwin

[Ken Brown <kbrown@cornell.edu>]

On 5/15/2009 10:16 AM, Eli Zaretskii wrote:
> There are also a few Cygwin-related problems in etc/PROBLEMS.

I've started looking at this, and it's not clear to me exactly what is
supposed to be in etc/PROBLEMS.  If a problem is solved, should the
discussion be updated to indicate what the solution was or should it
just be deleted?  Here's a specific example.  There is a discussion in
etc/PROBLEMS of a rebasing problem, followed by this workaround:

> To work around this, build Emacs like this:
> 
>   LDFLAGS='-Wl,--enable-auto-import -Wl,--enable-auto-image-base' ./configure
>   make LD='$(CC)'
>   make LD='$(CC)' install
> 
> This produces an Emacs binary that is independent of rebasing.
> 
> Note that you _must_ use LD='$(CC)' in the last two commands above, to
> prevent GCC from passing the "--image-base 0x20000000" option to the
> linker, which is what it does by default.  That option produces an
> Emacs binary with the base address 0x20000000, which will cause Emacs
> to hang after Cygwin DLLs are rebased.

But a much more straightforward solution to the problem is to apply the
following patch to src/s/cygwin.h:

--- origsrc/emacs-23.0.92/src/s/cygwin.h	2009-01-08 06:46:27.000000000 -0500
+++ src/emacs-23.0.92/src/s/cygwin.h	2009-05-17 11:40:55.812500000 -0400
@@ -108,8 +108,12 @@ along with GNU Emacs.  If not, see <http
  /* force the emacs image to start high in memory, so dll relocation
     can put things in low memory without causing all sorts of grief for
     emacs lisp pointers */
-#define DATA_SEG_BITS 0x20000000
-#define LINKER $(CC) -Wl,--image-base,DATA_SEG_BITS
+/* but this can cause problems if the user later rebases; so I'm
+   changing it (KB) */
+
+/* #define DATA_SEG_BITS 0x20000000 */
+/* #define LINKER $(CC) -Wl,--image-base,DATA_SEG_BITS */
+#define LINKER $(CC)

  /* Use terminfo instead of termcap.  Fewer environment variables to
     go wrong, more terminal types. */

If the emacs developers accept this patch, then we can just remove the
whole thing from etc/PROBLEMS.  Or is it better to just report that the
workaround is no longer needed as a result of the patch?

While I'm on the subject of cygwin.h, I asked one of the cygwin 
developers to look at that file and see if it seems reasonable.  He had 
a couple of comments:

 > #define PTY_OPEN					\
 > >  do							\
 > >    {							\
 > >      int dummy;					\
 > >      SIGMASKTYPE mask;					\
 > >      mask = sigblock (sigmask (SIGCHLD));		\
 > >      if (-1 == openpty (&fd, &dummy, pty_name, 0, 0))	\
 > >	fd = -1;					\
 > >      sigsetmask (mask);				\
 > >      emacs_close (dummy);				\

 > This will close a random number if openpty fails.

 > > #define vfork fork

 > This is a no-op since vfork == fork.

Ken