Re: New emacs maintainer for cygwin

[Ken Brown]

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