From: Ken Brown <kbrown@cornell.edu>
To: "Jan Djärv" <jan.h.d@swipnet.se>
Cc: Stefan Monnier <monnier@iro.umontreal.ca>, emacs-devel@gnu.org
Subject: Re: Fix for Cygwin/GSlice problem
Date: Wed, 09 Dec 2009 14:29:26 -0500 [thread overview]
Message-ID: <4B1FFA96.7000203@cornell.edu> (raw)
In-Reply-To: <4B1FF22D.8080800@swipnet.se>
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
next prev parent reply other threads:[~2009-12-09 19:29 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-12-08 19:24 Fix for Cygwin/GSlice problem 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 [this message]
2009-12-09 20:39 ` Jan Djärv
2009-12-10 12:16 ` Ken Brown
2009-12-09 17:31 ` Jan Djärv
-- strict thread matches above, loose matches on Subject: below --
2009-12-09 0:43 Angelo Graziosi
2009-12-15 16:06 Angelo Graziosi
2009-12-15 16:13 ` Chong Yidong
2009-12-15 16:18 ` Angelo Graziosi
2009-12-16 22:47 ` Angelo Graziosi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4B1FFA96.7000203@cornell.edu \
--to=kbrown@cornell.edu \
--cc=emacs-devel@gnu.org \
--cc=jan.h.d@swipnet.se \
--cc=monnier@iro.umontreal.ca \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).