Fix for Cygwin/GSlice problem

Fix for Cygwin/GSlice problem

[Ken Brown]

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

The attached patch fixes a longstanding problem with the Gtk+ build of 
emacs in Cygwin.  The problem is described in etc/PROBLEMS ("Emacs 
compiled with Gtk+ crashes on startup on Cygwin"), along with a 
workaround.  The patch simply incorporates that workaround into the 
emacs code.  I tried to do this so that the Cygwin-specific part is 
hidden in src/s/cygwin.h; it's conceivable that there are other systems 
where something similar would be useful.

The patch also removes the description of the problem from etc/PROBLEMS 
and removes a configuration warning.

Please apply the patch if it's OK, or tell me how to improve it.

Thanks.

Ken


[-- Attachment #2: gslice.patch --]
[-- Type: text/plain, Size: 2698 bytes --]

--- origsrc/emacs/src/s/cygwin.h	2009-11-20 23:50:36.000000000 -0500
+++ src/emacs/src/s/cygwin.h	2009-12-08 07:05:57.758985600 -0500
@@ -126,6 +126,12 @@ along with GNU Emacs.  If not, see <http
 /* Virtual addresses of pure and impure space can vary, as on Windows.  */
 #define VIRT_ADDR_VARIES
 
+/* Emacs supplies its own malloc, but glib (part of Gtk+) calls
+   memalign and on Cygwin, that becomes the Cygwin supplied memalign.
+   As malloc is not the Cygwin malloc, the Cygwin memalign always
+   returns ENOSYS.  A workaround is to set G_SLICE=always-malloc. */
+#define G_SLICE_ALWAYS_MALLOC
+
 /* the end */
 
 /* arch-tag: 5ae7ba00-83b0-4ab3-806a-3e845779191b
--- origsrc/emacs/src/emacs.c	2009-11-17 03:21:34.000000000 -0500
+++ src/emacs/src/emacs.c	2009-12-08 07:05:57.769000000 -0500
@@ -785,6 +785,9 @@ bug_reporting_address ()
 int
 main (int argc, char **argv)
 {
+# if defined (USE_GTK) && defined (G_SLICE_ALWAYS_MALLOC)
+  setenv("G_SLICE", "always-malloc", 1);
+#endif
 #if GC_MARK_STACK
   Lisp_Object dummy;
 #endif
--- origsrc/emacs/configure.in	2009-11-21 10:40:31.000000000 -0500
+++ src/emacs/configure.in	2009-12-08 07:05:57.809057600 -0500
@@ -3026,16 +3026,6 @@ fi
 
 echo
 
-if test "$USE_X_TOOLKIT" = GTK; then
-  case "$canonical" in
-  *cygwin*)
-    echo "There are known problems with Emacs and Gtk+ on cygwin, so you
-  will probably get a crash on startup.  If this happens, please use another
-  toolkit for Emacs.  See etc/PROBLEMS for more information."
-  ;;
-  esac
-fi
-
 if test "$HAVE_NS" = "yes"; then
    echo
    echo "You must run \"make install\" in order to test the built application.
--- origsrc/emacs/etc/PROBLEMS	2009-11-20 16:46:28.000000000 -0500
+++ src/emacs/etc/PROBLEMS	2009-12-08 07:08:07.655768000 -0500
@@ -244,28 +244,6 @@ frame on another X display, then a Gtk+ 
 server that results in an endless loop.  This is not fixed in any known
 Gtk+ version (2.14.4 being current).
 
-** Emacs compiled with Gtk+ crashes on startup on Cygwin.
-
-A typical error message is
-  ***MEMORY-ERROR***: emacs[5172]: GSlice: failed to allocate 504 bytes
-  (alignment: 512): Function not implemented
-
-Emacs supplies its own malloc, but glib (part of Gtk+) calls memalign and on
-Cygwin, that becomes the Cygwin supplied memalign.  As malloc is not the
-Cygwin malloc, the Cygwin memalign always returns ENOSYS.
-
-One workaround is to set G_SLICE=always-malloc before starting emacs.
-For example, in bash,
-
-  G_SLICE=always-malloc emacs
-
-or put
-
-  export G_SLICE=always-malloc
-
-in one of the bash startup files.  This also has to be done before
-building emacs on Cygwin with Gtk+.
-
 * General runtime problems
 
 ** Lisp problems

Re: Fix for Cygwin/GSlice problem

[Chong Yidong]

Ken Brown <kbrown@cornell.edu> writes:

> The attached patch fixes a longstanding problem with the Gtk+ build of
> emacs in Cygwin.  The problem is described in etc/PROBLEMS ("Emacs
> compiled with Gtk+ crashes on startup on Cygwin"), along with a
> workaround.  The patch simply incorporates that workaround into the
> emacs code.  I tried to do this so that the Cygwin-specific part is
> hidden in src/s/cygwin.h; it's conceivable that there are other
> systems where something similar would be useful.
>
> The patch also removes the description of the problem from
> etc/PROBLEMS and removes a configuration warning.
>
> Please apply the patch if it's OK, or tell me how to improve it.

Looks OK to me.  Applied; thanks.

Re: Fix for Cygwin/GSlice problem

[Stefan Monnier]

> +/* Emacs supplies its own malloc, but glib (part of Gtk+) calls
> +   memalign and on Cygwin, that becomes the Cygwin supplied memalign.
> +   As malloc is not the Cygwin malloc, the Cygwin memalign always
> +   returns ENOSYS.  A workaround is to set G_SLICE=always-malloc. */
> +#define G_SLICE_ALWAYS_MALLOC

Why does Cygwin-Emacs use its own malloc rather than the system malloc?


        Stefan

Re: Fix for Cygwin/GSlice problem

[Ken Brown]

On 12/8/2009 8:33 PM, Stefan Monnier wrote:
>> +/* Emacs supplies its own malloc, but glib (part of Gtk+) calls
>> +   memalign and on Cygwin, that becomes the Cygwin supplied memalign.
>> +   As malloc is not the Cygwin malloc, the Cygwin memalign always
>> +   returns ENOSYS.  A workaround is to set G_SLICE=always-malloc. */
>> +#define G_SLICE_ALWAYS_MALLOC
> 
> Why does Cygwin-Emacs use its own malloc rather than the system malloc?

There was a long thread about this on the Cygwin list in 2007, in which 
Jan Djärv tried to sort this out.  It starts at

   http://cygwin.com/ml/cygwin/2007-02/threads.html#00469

and continues at

   http://cygwin.com/ml/cygwin/2007-02/threads.html#00503

I'm afraid a lot of that discussion is over my head.  All I can say is 
that the Emacs build brings in the Emacs malloc and friends, but when 
glib calls memalign, the Cygwin memalign gets called instead of the one 
supplied by Emacs.  Maybe Jan can explain why it wasn't possible to 
change this or to simply use Cygwin's malloc and friends.  He seemed 
optimistic at the end of thread, but then the discussion stopped.

Ken

Re: Fix for Cygwin/GSlice problem

[Jan D.]

On 2009-12-09 04:06, Ken Brown wrote:
> On 12/8/2009 8:33 PM, Stefan Monnier wrote:
>>> +/* Emacs supplies its own malloc, but glib (part of Gtk+) calls
>>> + memalign and on Cygwin, that becomes the Cygwin supplied memalign.
>>> + As malloc is not the Cygwin malloc, the Cygwin memalign always
>>> + returns ENOSYS. A workaround is to set G_SLICE=always-malloc. */
>>> +#define G_SLICE_ALWAYS_MALLOC
>>
>> Why does Cygwin-Emacs use its own malloc rather than the system malloc?

Emacs prefers its own malloc when the system malloc doesn't have the 
required hooks.  If this is critical or not I don't know.

>
> There was a long thread about this on the Cygwin list in 2007, in which
> Jan Djärv tried to sort this out. It starts at
>
> http://cygwin.com/ml/cygwin/2007-02/threads.html#00469
>
> and continues at
>
> http://cygwin.com/ml/cygwin/2007-02/threads.html#00503
>
> I'm afraid a lot of that discussion is over my head. All I can say is
> that the Emacs build brings in the Emacs malloc and friends, but when
> glib calls memalign, the Cygwin memalign gets called instead of the one
> supplied by Emacs. Maybe Jan can explain why it wasn't possible to
> change this or to simply use Cygwin's malloc and friends. He seemed
> optimistic at the end of thread, but then the discussion stopped.

I think it stopped because it came down to the way Cygwin handles 
linking of malloc and friends.  I don't understand why Cygwin doesn't 
allow an application to have its own memalign, but do allow it to have 
its own malloc.

	Jan D.

Re: Fix for Cygwin/GSlice problem

[Stefan Monnier]

>>>> +/* Emacs supplies its own malloc, but glib (part of Gtk+) calls
>>>> + memalign and on Cygwin, that becomes the Cygwin supplied memalign.
>>>> + As malloc is not the Cygwin malloc, the Cygwin memalign always
>>>> + returns ENOSYS. A workaround is to set G_SLICE=always-malloc. */
>>>> +#define G_SLICE_ALWAYS_MALLOC
>>> Why does Cygwin-Emacs use its own malloc rather than the system malloc?
> Emacs prefers its own malloc when the system malloc doesn't have the
> required hooks.  If this is critical or not I don't know.

I'd suggest we try to use Cygwin's system malloc, with a clear comment
about why we don't use our own, and what kind of workaround could be
used (the G_SLICE_ALWAYS_MALLOC) if we wanted to use our own.

FWIW, the malloc hooks such as __malloc_hook are only used when building
without SYNC_INPUT, so now that we use SNYC_INPUT by default, it's not
as important to use our own malloc any more.

> I think it stopped because it came down to the way Cygwin handles
> linking of malloc and friends.  I don't understand why Cygwin doesn't
> allow an application to have its own memalign, but do allow it to have
> its own malloc.

Maybe that's a bug in Cygwin's malloc.


        Stefan

Re: Fix for Cygwin/GSlice problem

[Ken Brown]

On 12/9/2009 9:31 AM, Stefan Monnier wrote:
>>>>> +/* Emacs supplies its own malloc, but glib (part of Gtk+) calls
>>>>> + memalign and on Cygwin, that becomes the Cygwin supplied memalign.
>>>>> + As malloc is not the Cygwin malloc, the Cygwin memalign always
>>>>> + returns ENOSYS. A workaround is to set G_SLICE=always-malloc. */
>>>>> +#define G_SLICE_ALWAYS_MALLOC
>>>> Why does Cygwin-Emacs use its own malloc rather than the system malloc?
>> Emacs prefers its own malloc when the system malloc doesn't have the
>> required hooks.  If this is critical or not I don't know.
> 
> I'd suggest we try to use Cygwin's system malloc, with a clear comment
> about why we don't use our own, and what kind of workaround could be
> used (the G_SLICE_ALWAYS_MALLOC) if we wanted to use our own.

OK, I'll give it a try and report back.  I assume the way to do this is 
to remove '#define G_SLICE_ALWAYS_MALLOC' from src/s/cygwin.h and 
instead #define SYSTEM_MALLOC.  [You don't need to respond unless this 
is wrong.]

Ken

Re: Fix for Cygwin/GSlice problem

[Ken Brown]

On 12/9/2009 10:00 AM, Ken Brown wrote:
> On 12/9/2009 9:31 AM, Stefan Monnier wrote:
>>>>>> +/* Emacs supplies its own malloc, but glib (part of Gtk+) calls
>>>>>> + memalign and on Cygwin, that becomes the Cygwin supplied memalign.
>>>>>> + As malloc is not the Cygwin malloc, the Cygwin memalign always
>>>>>> + returns ENOSYS. A workaround is to set G_SLICE=always-malloc. */
>>>>>> +#define G_SLICE_ALWAYS_MALLOC
>>>>> Why does Cygwin-Emacs use its own malloc rather than the system 
>>>>> malloc?
>>> Emacs prefers its own malloc when the system malloc doesn't have the
>>> required hooks.  If this is critical or not I don't know.
>>
>> I'd suggest we try to use Cygwin's system malloc, with a clear comment
>> about why we don't use our own, and what kind of workaround could be
>> used (the G_SLICE_ALWAYS_MALLOC) if we wanted to use our own.
> 
> OK, I'll give it a try and report back.  I assume the way to do this is 
> to remove '#define G_SLICE_ALWAYS_MALLOC' from src/s/cygwin.h and 
> instead #define SYSTEM_MALLOC.  [You don't need to respond unless this 
> is wrong.]

I tried this, and the build fails with

gcc    -o temacs ecrt0.o dispnew.o frame.o scroll.o xdisp.o menu.o 
window.o charset.o coding.o category.o ccl.o character.o chartab.o cm.o 
term.o terminal.o xfaces.o    emacs.o keyboard.o macros.o keymap.o 
sysdep.o buffer.o filelock.o insdel.o marker.o minibuf.o fileio.o 
dired.o filemode.o cmds.o casetab.o casefiddle.o indent.o search.o 
regex.o undo.o alloc.o data.o doc.o editfns.o callint.o eval.o 
floatfns.o fns.o font.o print.o lread.o syntax.o unexcw.o bytecode.o 
process.o callproc.o region-cache.o sound.o atimer.o doprnt.o strftime.o 
intervals.o textprop.o composite.o md5.o   sheap.o  terminfo.o 
lastfile.o vm-limit.o  getloadavg.o       -lcurses -lg   `gcc 
-print-libgcc-file-name` -lm -lc `gcc -print-libgcc-file-name`
vm-limit.o:vm-limit.c:(.text+0x17): undefined reference to 
`___after_morecore_hook'
vm-limit.o:vm-limit.c:(.text+0x6c): undefined reference to `___morecore'

I looked at the source code, and I can't see any place where Cygwin's 
malloc.h is getting included.  I don't know if that's the (only) problem.

I also asked for help on the Cygwin list and got the following two 
responses:

> ...cygwin doesn't provide something
> that linux does.  It's possible that you may be able to work around
> the problem by using a -D__morecore=sbrk (or maybe one more underscore
> is needed) on the compile line for vm-limit.c.

> why are you bothering to specify the system libs at all?  You're using
> the gcc driver to link, it'll do all that for you automatically (and
> correctly) if you just leave them out; you shouldn't need anything but
> -lcurses out of that lot.  You'll definitely break linking against the shared
> libgcc by putting the static archive in the list of user libraries like that.

I'm really in over my head at this point.  If someone sees something I 
can do to fix this, I'll give it a try.  Otherwise, maybe we should just 
stick with the G_SLICE workaround for now.

Ken

Re: Fix for Cygwin/GSlice problem

[Jan Djärv]

Ken Brown skrev:
> On 12/9/2009 10:00 AM, Ken Brown wrote:
>> On 12/9/2009 9:31 AM, Stefan Monnier wrote:
>>>>>>> +/* Emacs supplies its own malloc, but glib (part of Gtk+) calls
>>>>>>> + memalign and on Cygwin, that becomes the Cygwin supplied memalign.
>>>>>>> + As malloc is not the Cygwin malloc, the Cygwin memalign always
>>>>>>> + returns ENOSYS. A workaround is to set G_SLICE=always-malloc. */
>>>>>>> +#define G_SLICE_ALWAYS_MALLOC
>>>>>> Why does Cygwin-Emacs use its own malloc rather than the system 
>>>>>> malloc?
>>>> Emacs prefers its own malloc when the system malloc doesn't have the
>>>> required hooks.  If this is critical or not I don't know.
>>>
>>> I'd suggest we try to use Cygwin's system malloc, with a clear comment
>>> about why we don't use our own, and what kind of workaround could be
>>> used (the G_SLICE_ALWAYS_MALLOC) if we wanted to use our own.
>>
>> OK, I'll give it a try and report back.  I assume the way to do this 
>> is to remove '#define G_SLICE_ALWAYS_MALLOC' from src/s/cygwin.h and 
>> instead #define SYSTEM_MALLOC.  [You don't need to respond unless this 
>> is wrong.]
> 
> I tried this, and the build fails with
> 
> gcc    -o temacs ecrt0.o dispnew.o frame.o scroll.o xdisp.o menu.o 
> window.o charset.o coding.o category.o ccl.o character.o chartab.o cm.o 
> term.o terminal.o xfaces.o    emacs.o keyboard.o macros.o keymap.o 
> sysdep.o buffer.o filelock.o insdel.o marker.o minibuf.o fileio.o 
> dired.o filemode.o cmds.o casetab.o casefiddle.o indent.o search.o 
> regex.o undo.o alloc.o data.o doc.o editfns.o callint.o eval.o 
> floatfns.o fns.o font.o print.o lread.o syntax.o unexcw.o bytecode.o 
> process.o callproc.o region-cache.o sound.o atimer.o doprnt.o strftime.o 
> intervals.o textprop.o composite.o md5.o   sheap.o  terminfo.o 
> lastfile.o vm-limit.o  getloadavg.o       -lcurses -lg   `gcc 
> -print-libgcc-file-name` -lm -lc `gcc -print-libgcc-file-name`
> vm-limit.o:vm-limit.c:(.text+0x17): undefined reference to 
> `___after_morecore_hook'
> vm-limit.o:vm-limit.c:(.text+0x6c): undefined reference to `___morecore'
> 
> I looked at the source code, and I can't see any place where Cygwin's 
> malloc.h is getting included.  I don't know if that's the (only) problem.
> 
> I also asked for help on the Cygwin list and got the following two 
> responses:
> 
>> ...cygwin doesn't provide something
>> that linux does.  It's possible that you may be able to work around
>> the problem by using a -D__morecore=sbrk (or maybe one more underscore
>> is needed) on the compile line for vm-limit.c.
> 
>> why are you bothering to specify the system libs at all?  You're using
>> the gcc driver to link, it'll do all that for you automatically (and
>> correctly) if you just leave them out; you shouldn't need anything but
>> -lcurses out of that lot.  You'll definitely break linking against the 
>> shared
>> libgcc by putting the static archive in the list of user libraries 
>> like that.
> 
> I'm really in over my head at this point.  If someone sees something I 
> can do to fix this, I'll give it a try.  Otherwise, maybe we should just 
> stick with the G_SLICE workaround for now.
> 

You should be able to just comment out the lines in vm-limit.c, i.e. just put

void
memory_warnings (start, warnfun)
      POINTER start;
      void (*warnfun) ();
{
#ifndef CYGWIN
  ...
#endif
}

so you can test it.

The comments about static and dynamic libraries are in principle correct, but 
Emacs whats to do it like that for the sake of dumping.  But my guess is that 
it may be redundant now, but since it works, nobody has tried to change it. 
There are a few platforms to test it on so why bother?

	Jan D.

Re: Fix for Cygwin/GSlice problem

[Ken Brown]

On 12/9/2009 1:53 PM, Jan Djärv wrote:
> Ken Brown skrev:
>> On 12/9/2009 10:00 AM, Ken Brown wrote:
>>> On 12/9/2009 9:31 AM, Stefan Monnier wrote:
>>>>>>>> +/* Emacs supplies its own malloc, but glib (part of Gtk+) calls
>>>>>>>> + memalign and on Cygwin, that becomes the Cygwin supplied 
>>>>>>>> memalign.
>>>>>>>> + As malloc is not the Cygwin malloc, the Cygwin memalign always
>>>>>>>> + returns ENOSYS. A workaround is to set G_SLICE=always-malloc. */
>>>>>>>> +#define G_SLICE_ALWAYS_MALLOC
>>>>>>> Why does Cygwin-Emacs use its own malloc rather than the system 
>>>>>>> malloc?
>>>>> Emacs prefers its own malloc when the system malloc doesn't have the
>>>>> required hooks.  If this is critical or not I don't know.
>>>>
>>>> I'd suggest we try to use Cygwin's system malloc, with a clear comment
>>>> about why we don't use our own, and what kind of workaround could be
>>>> used (the G_SLICE_ALWAYS_MALLOC) if we wanted to use our own.
>>>
>>> OK, I'll give it a try and report back.  I assume the way to do this 
>>> is to remove '#define G_SLICE_ALWAYS_MALLOC' from src/s/cygwin.h and 
>>> instead #define SYSTEM_MALLOC.  [You don't need to respond unless 
>>> this is wrong.]
>>
>> I tried this, and the build fails with
>>
>> gcc    -o temacs ecrt0.o dispnew.o frame.o scroll.o xdisp.o menu.o 
>> window.o charset.o coding.o category.o ccl.o character.o chartab.o 
>> cm.o term.o terminal.o xfaces.o    emacs.o keyboard.o macros.o 
>> keymap.o sysdep.o buffer.o filelock.o insdel.o marker.o minibuf.o 
>> fileio.o dired.o filemode.o cmds.o casetab.o casefiddle.o indent.o 
>> search.o regex.o undo.o alloc.o data.o doc.o editfns.o callint.o 
>> eval.o floatfns.o fns.o font.o print.o lread.o syntax.o unexcw.o 
>> bytecode.o process.o callproc.o region-cache.o sound.o atimer.o 
>> doprnt.o strftime.o intervals.o textprop.o composite.o md5.o   
>> sheap.o  terminfo.o lastfile.o vm-limit.o  getloadavg.o       -lcurses 
>> -lg   `gcc -print-libgcc-file-name` -lm -lc `gcc -print-libgcc-file-name`
>> vm-limit.o:vm-limit.c:(.text+0x17): undefined reference to 
>> `___after_morecore_hook'
>> vm-limit.o:vm-limit.c:(.text+0x6c): undefined reference to `___morecore'
>>
>> I looked at the source code, and I can't see any place where Cygwin's 
>> malloc.h is getting included.  I don't know if that's the (only) problem.
>>
>> I also asked for help on the Cygwin list and got the following two 
>> responses:
>>
>>> ...cygwin doesn't provide something
>>> that linux does.  It's possible that you may be able to work around
>>> the problem by using a -D__morecore=sbrk (or maybe one more underscore
>>> is needed) on the compile line for vm-limit.c.
>>
>>> why are you bothering to specify the system libs at all?  You're using
>>> the gcc driver to link, it'll do all that for you automatically (and
>>> correctly) if you just leave them out; you shouldn't need anything but
>>> -lcurses out of that lot.  You'll definitely break linking against 
>>> the shared
>>> libgcc by putting the static archive in the list of user libraries 
>>> like that.
>>
>> I'm really in over my head at this point.  If someone sees something I 
>> can do to fix this, I'll give it a try.  Otherwise, maybe we should 
>> just stick with the G_SLICE workaround for now.
>>
> 
> You should be able to just comment out the lines in vm-limit.c, i.e. 
> just put
> 
> void
> memory_warnings (start, warnfun)
>      POINTER start;
>      void (*warnfun) ();
> {
> #ifndef CYGWIN
>  ...
> #endif
> }
> 
> so you can test it.

OK, I'll try this when I get a chance.

> The comments about static and dynamic libraries are in principle 
> correct, but Emacs whats to do it like that for the sake of dumping.  
> But my guess is that it may be redundant now, but since it works, nobody 
> has tried to change it. There are a few platforms to test it on so why 
> bother?

Those comments came from Dave Korn, who is Cygwin's gcc maintainer.  If 
he's right that it breaks linking against the shared libgcc, I wonder if 
that's been the problem all along.  As I recall from the February 2007 
thread, there was a suggestion that there were linking problems that 
prevented Emacs's memalign from being called by glib.

Is there a way I can disable linking against the static libgcc just to 
see what happens?

Ken

Re: Fix for Cygwin/GSlice problem

[Jan Djärv]

Ken Brown skrev 2009-12-09 20.29:
> Those comments came from Dave Korn, who is Cygwin's gcc maintainer. If
> he's right that it breaks linking against the shared libgcc, I wonder if
> that's been the problem all along. As I recall from the February 2007
> thread, there was a suggestion that there were linking problems that
> prevented Emacs's memalign from being called by glib.
>
> Is there a way I can disable linking against the static libgcc just to
> see what happens?
>

Just remove those `gcc -print-libgcc-file-name` from the makefile.

	Jan D.

Re: Fix for Cygwin/GSlice problem

[Ken Brown]

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

On 12/9/2009 1:53 PM, Jan Djärv wrote:
> Ken Brown skrev:
>> On 12/9/2009 10:00 AM, Ken Brown wrote:
>>> On 12/9/2009 9:31 AM, Stefan Monnier wrote:
>>>>>>>> +/* Emacs supplies its own malloc, but glib (part of Gtk+) calls
>>>>>>>> + memalign and on Cygwin, that becomes the Cygwin supplied 
>>>>>>>> memalign.
>>>>>>>> + As malloc is not the Cygwin malloc, the Cygwin memalign always
>>>>>>>> + returns ENOSYS. A workaround is to set G_SLICE=always-malloc. */
>>>>>>>> +#define G_SLICE_ALWAYS_MALLOC
>>>>>>> Why does Cygwin-Emacs use its own malloc rather than the system 
>>>>>>> malloc?
>>>>> Emacs prefers its own malloc when the system malloc doesn't have the
>>>>> required hooks.  If this is critical or not I don't know.
>>>>
>>>> I'd suggest we try to use Cygwin's system malloc, with a clear comment
>>>> about why we don't use our own, and what kind of workaround could be
>>>> used (the G_SLICE_ALWAYS_MALLOC) if we wanted to use our own.
>>>
>>> OK, I'll give it a try and report back.  I assume the way to do this 
>>> is to remove '#define G_SLICE_ALWAYS_MALLOC' from src/s/cygwin.h and 
>>> instead #define SYSTEM_MALLOC.  [You don't need to respond unless 
>>> this is wrong.]
>>
>> I tried this, and the build fails with
>>
>> gcc    -o temacs ecrt0.o dispnew.o frame.o scroll.o xdisp.o menu.o 
>> window.o charset.o coding.o category.o ccl.o character.o chartab.o 
>> cm.o term.o terminal.o xfaces.o    emacs.o keyboard.o macros.o 
>> keymap.o sysdep.o buffer.o filelock.o insdel.o marker.o minibuf.o 
>> fileio.o dired.o filemode.o cmds.o casetab.o casefiddle.o indent.o 
>> search.o regex.o undo.o alloc.o data.o doc.o editfns.o callint.o 
>> eval.o floatfns.o fns.o font.o print.o lread.o syntax.o unexcw.o 
>> bytecode.o process.o callproc.o region-cache.o sound.o atimer.o 
>> doprnt.o strftime.o intervals.o textprop.o composite.o md5.o   
>> sheap.o  terminfo.o lastfile.o vm-limit.o  getloadavg.o       -lcurses 
>> -lg   `gcc -print-libgcc-file-name` -lm -lc `gcc -print-libgcc-file-name`
>> vm-limit.o:vm-limit.c:(.text+0x17): undefined reference to 
>> `___after_morecore_hook'
>> vm-limit.o:vm-limit.c:(.text+0x6c): undefined reference to `___morecore'
>>
>> I looked at the source code, and I can't see any place where Cygwin's 
>> malloc.h is getting included.  I don't know if that's the (only) problem.
>>
>> I also asked for help on the Cygwin list and got the following two 
>> responses:
>>
>>> ...cygwin doesn't provide something
>>> that linux does.  It's possible that you may be able to work around
>>> the problem by using a -D__morecore=sbrk (or maybe one more underscore
>>> is needed) on the compile line for vm-limit.c.
>>
>>> why are you bothering to specify the system libs at all?  You're using
>>> the gcc driver to link, it'll do all that for you automatically (and
>>> correctly) if you just leave them out; you shouldn't need anything but
>>> -lcurses out of that lot.  You'll definitely break linking against 
>>> the shared
>>> libgcc by putting the static archive in the list of user libraries 
>>> like that.
>>
>> I'm really in over my head at this point.  If someone sees something I 
>> can do to fix this, I'll give it a try.  Otherwise, maybe we should 
>> just stick with the G_SLICE workaround for now.
>>
> 
> You should be able to just comment out the lines in vm-limit.c, i.e. 
> just put
> 
> void
> memory_warnings (start, warnfun)
>      POINTER start;
>      void (*warnfun) ();
> {
> #ifndef CYGWIN
>  ...
> #endif
> }
> 
> so you can test it.

OK, this enables the compilation to complete, but the resulting emacs
crashes with a segfault, even with G_SLICE=always-malloc.  And disabling
linking against static libgcc doesn't help either.  I think we should
stick with the Emacs malloc and the G_SLICE workaround.

Even though Dave Korn's advice about libraries turned out to be 
irrelevant for this issue, I still think it would be wise to follow it. 
  The attached patch accomplishes this.  Could someone please apply it?

Thanks.

Ken

[-- Attachment #2: libs.patch --]
[-- Type: text/plain, Size: 557 bytes --]

--- origsrc/emacs-23.1.90/src/s/cygwin.h	2009-12-08 20:01:43.000000000 -0500
+++ src/emacs-23.1.90/src/s/cygwin.h	2009-12-09 22:11:24.320763600 -0500
@@ -132,6 +132,14 @@ along with GNU Emacs.  If not, see <http
    returns ENOSYS.  A workaround is to set G_SLICE=always-malloc. */
 #define G_SLICE_ALWAYS_MALLOC
 
+/* Don't link against static libgcc */
+#define LIB_GCC
+
+/* Don't list standard libs on link command line */
+#define LIB_STANDARD
+#define LIB_MATH
+#define LIBS_DEBUG
+
 /* the end */
 
 /* arch-tag: 5ae7ba00-83b0-4ab3-806a-3e845779191b

Re: Fix for Cygwin/GSlice problem

[Jan Djärv]

Stefan Monnier skrev 2009-12-09 15.31:

>
>> I think it stopped because it came down to the way Cygwin handles
>> linking of malloc and friends.  I don't understand why Cygwin doesn't
>> allow an application to have its own memalign, but do allow it to have
>> its own malloc.
>
> Maybe that's a bug in Cygwin's malloc.
>

It is missing code in the Cygwin dll:s.  Code exists to allow applications to 
have their own malloc, but the equivalent code for memalign just returns 
ENOSYS.  For some reason or another, they don't fix it.

	Jan D.

Re: Fix for Cygwin/GSlice problem

[Angelo Graziosi]

Ken Brown wrote:
> The attached patch fixes a longstanding problem with the Gtk+ build of emacs in Cygwin.

+1

It works just fine!

Thanks,
Angelo

Re: Fix for Cygwin/GSlice problem

[Angelo Graziosi]

Ken Brown wrote[*]:
> Could someone please apply it?

Ping?

Thanks,
Angelo.


---
http://lists.gnu.org/archive/html/emacs-devel/2009-12/msg00493.html

Re: Fix for Cygwin/GSlice problem

[Chong Yidong]

Angelo Graziosi <angelo.graziosi@alice.it> writes:

> Ken Brown wrote[*]:
>> Could someone please apply it?
>
> Ping?

It is already in the repository since last week.

Re: Fix for Cygwin/GSlice problem

[Angelo Graziosi]

Il 15/12/2009 17.13, Chong Yidong ha scritto:
> Angelo Graziosi<angelo.graziosi@alice.it>  writes:
>
>> Ken Brown wrote[*]:
>>> Could someone please apply it?
>>
>> Ping?
>
> It is already in the repository since last week.

Sure? In CVS?

I think that was another patch... See libs.patch here:

http://lists.gnu.org/archive/html/emacs-devel/2009-12/msg00493.html

Cheers,
Angelo.

Re: Fix for Cygwin/GSlice problem

[Angelo Graziosi]

Il 15/12/2009 17.13, Chong Yidong ha scritto:
> Angelo Graziosi writes:
>
>> Ken Brown wrote[*]:
>>> Could someone please apply it?
>>
>> Ping?
>
> It is already in the repository since last week.

The patch you are referring (gslice.patch) is described here:

http://lists.gnu.org/archive/html/emacs-devel/2009-12/msg00369.html

But *here* :

http://lists.gnu.org/archive/html/emacs-devel/2009-12/msg00493.html

there is described another patch (libs.patch) not yet applied to CVS head...

> Could someone please apply it?


Thanks,
Angelo.