* Fix for Cygwin/GSlice problem
@ 2009-12-08 19:24 Ken Brown
2009-12-09 1:07 ` Chong Yidong
2009-12-09 1:33 ` Stefan Monnier
0 siblings, 2 replies; 18+ messages in thread
From: Ken Brown @ 2009-12-08 19:24 UTC (permalink / raw
To: emacs-devel
[-- 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
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Fix for Cygwin/GSlice problem
@ 2009-12-09 0:43 Angelo Graziosi
0 siblings, 0 replies; 18+ messages in thread
From: Angelo Graziosi @ 2009-12-09 0:43 UTC (permalink / raw
To: Emacs
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
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Fix for Cygwin/GSlice problem
2009-12-08 19:24 Ken Brown
@ 2009-12-09 1:07 ` Chong Yidong
2009-12-09 1:33 ` Stefan Monnier
1 sibling, 0 replies; 18+ messages in thread
From: Chong Yidong @ 2009-12-09 1:07 UTC (permalink / raw
To: Ken Brown; +Cc: emacs-devel
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.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Fix for Cygwin/GSlice problem
2009-12-08 19:24 Ken Brown
2009-12-09 1:07 ` Chong Yidong
@ 2009-12-09 1:33 ` Stefan Monnier
2009-12-09 3:06 ` Ken Brown
1 sibling, 1 reply; 18+ messages in thread
From: Stefan Monnier @ 2009-12-09 1:33 UTC (permalink / raw
To: Ken Brown; +Cc: emacs-devel
> +/* 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
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Fix for Cygwin/GSlice problem
2009-12-09 1:33 ` Stefan Monnier
@ 2009-12-09 3:06 ` Ken Brown
2009-12-09 8:05 ` Jan D.
0 siblings, 1 reply; 18+ messages in thread
From: Ken Brown @ 2009-12-09 3:06 UTC (permalink / raw
To: Stefan Monnier; +Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Fix for Cygwin/GSlice problem
2009-12-09 3:06 ` Ken Brown
@ 2009-12-09 8:05 ` Jan D.
2009-12-09 14:31 ` Stefan Monnier
0 siblings, 1 reply; 18+ messages in thread
From: Jan D. @ 2009-12-09 8:05 UTC (permalink / raw
To: Ken Brown; +Cc: Stefan Monnier, emacs-devel
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.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Fix for Cygwin/GSlice problem
2009-12-09 8:05 ` Jan D.
@ 2009-12-09 14:31 ` Stefan Monnier
2009-12-09 15:00 ` Ken Brown
2009-12-09 17:31 ` Jan Djärv
0 siblings, 2 replies; 18+ messages in thread
From: Stefan Monnier @ 2009-12-09 14:31 UTC (permalink / raw
To: Jan D.; +Cc: Ken Brown, emacs-devel
>>>> +/* 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
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Fix for Cygwin/GSlice problem
2009-12-09 14:31 ` Stefan Monnier
@ 2009-12-09 15:00 ` Ken Brown
2009-12-09 16:30 ` Ken Brown
2009-12-09 17:31 ` Jan Djärv
1 sibling, 1 reply; 18+ messages in thread
From: Ken Brown @ 2009-12-09 15:00 UTC (permalink / raw
To: Stefan Monnier; +Cc: Jan D., emacs-devel
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
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Fix for Cygwin/GSlice problem
2009-12-09 15:00 ` Ken Brown
@ 2009-12-09 16:30 ` Ken Brown
2009-12-09 18:53 ` Jan Djärv
0 siblings, 1 reply; 18+ messages in thread
From: Ken Brown @ 2009-12-09 16:30 UTC (permalink / raw
To: Stefan Monnier; +Cc: Jan D., emacs-devel
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
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Fix for Cygwin/GSlice problem
2009-12-09 14:31 ` Stefan Monnier
2009-12-09 15:00 ` Ken Brown
@ 2009-12-09 17:31 ` Jan Djärv
1 sibling, 0 replies; 18+ messages in thread
From: Jan Djärv @ 2009-12-09 17:31 UTC (permalink / raw
To: Stefan Monnier; +Cc: Ken Brown, emacs-devel
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.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Fix for Cygwin/GSlice problem
2009-12-09 16:30 ` Ken Brown
@ 2009-12-09 18:53 ` Jan Djärv
2009-12-09 19:29 ` Ken Brown
2009-12-10 12:16 ` Ken Brown
0 siblings, 2 replies; 18+ messages in thread
From: Jan Djärv @ 2009-12-09 18:53 UTC (permalink / raw
To: Ken Brown; +Cc: Stefan Monnier, emacs-devel
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.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Fix for Cygwin/GSlice problem
2009-12-09 18:53 ` Jan Djärv
@ 2009-12-09 19:29 ` Ken Brown
2009-12-09 20:39 ` Jan Djärv
2009-12-10 12:16 ` Ken Brown
1 sibling, 1 reply; 18+ messages in thread
From: Ken Brown @ 2009-12-09 19:29 UTC (permalink / raw
To: Jan Djärv; +Cc: Stefan Monnier, emacs-devel
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
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Fix for Cygwin/GSlice problem
2009-12-09 19:29 ` Ken Brown
@ 2009-12-09 20:39 ` Jan Djärv
0 siblings, 0 replies; 18+ messages in thread
From: Jan Djärv @ 2009-12-09 20:39 UTC (permalink / raw
To: Ken Brown; +Cc: Stefan Monnier, emacs-devel
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.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Fix for Cygwin/GSlice problem
2009-12-09 18:53 ` Jan Djärv
2009-12-09 19:29 ` Ken Brown
@ 2009-12-10 12:16 ` Ken Brown
1 sibling, 0 replies; 18+ messages in thread
From: Ken Brown @ 2009-12-10 12:16 UTC (permalink / raw
To: Jan Djärv; +Cc: Stefan Monnier, emacs-devel
[-- 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
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Fix for Cygwin/GSlice problem
@ 2009-12-15 16:06 Angelo Graziosi
2009-12-15 16:13 ` Chong Yidong
0 siblings, 1 reply; 18+ messages in thread
From: Angelo Graziosi @ 2009-12-15 16:06 UTC (permalink / raw
To: Emacs
Ken Brown wrote[*]:
> Could someone please apply it?
Ping?
Thanks,
Angelo.
---
http://lists.gnu.org/archive/html/emacs-devel/2009-12/msg00493.html
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Fix for Cygwin/GSlice problem
2009-12-15 16:06 Fix for Cygwin/GSlice problem Angelo Graziosi
@ 2009-12-15 16:13 ` Chong Yidong
2009-12-15 16:18 ` Angelo Graziosi
2009-12-16 22:47 ` Angelo Graziosi
0 siblings, 2 replies; 18+ messages in thread
From: Chong Yidong @ 2009-12-15 16:13 UTC (permalink / raw
To: Angelo Graziosi; +Cc: Emacs
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.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Fix for Cygwin/GSlice problem
2009-12-15 16:13 ` Chong Yidong
@ 2009-12-15 16:18 ` Angelo Graziosi
2009-12-16 22:47 ` Angelo Graziosi
1 sibling, 0 replies; 18+ messages in thread
From: Angelo Graziosi @ 2009-12-15 16:18 UTC (permalink / raw
To: Chong Yidong; +Cc: Emacs
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.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Fix for Cygwin/GSlice problem
2009-12-15 16:13 ` Chong Yidong
2009-12-15 16:18 ` Angelo Graziosi
@ 2009-12-16 22:47 ` Angelo Graziosi
1 sibling, 0 replies; 18+ messages in thread
From: Angelo Graziosi @ 2009-12-16 22:47 UTC (permalink / raw
To: Chong Yidong; +Cc: Emacs
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.
^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2009-12-16 22:47 UTC | newest]
Thread overview: 18+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-12-15 16:06 Fix for Cygwin/GSlice problem Angelo Graziosi
2009-12-15 16:13 ` Chong Yidong
2009-12-15 16:18 ` Angelo Graziosi
2009-12-16 22:47 ` Angelo Graziosi
-- strict thread matches above, loose matches on Subject: below --
2009-12-09 0:43 Angelo Graziosi
2009-12-08 19:24 Ken Brown
2009-12-09 1:07 ` Chong Yidong
2009-12-09 1:33 ` Stefan Monnier
2009-12-09 3:06 ` Ken Brown
2009-12-09 8:05 ` Jan D.
2009-12-09 14:31 ` Stefan Monnier
2009-12-09 15:00 ` Ken Brown
2009-12-09 16:30 ` Ken Brown
2009-12-09 18:53 ` Jan Djärv
2009-12-09 19:29 ` Ken Brown
2009-12-09 20:39 ` Jan Djärv
2009-12-10 12:16 ` Ken Brown
2009-12-09 17:31 ` Jan Djärv
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.