From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Ken Brown Newsgroups: gmane.emacs.devel Subject: Re: Fix for Cygwin/GSlice problem Date: Thu, 10 Dec 2009 07:16:07 -0500 Message-ID: <4B20E687.5020403@cornell.edu> References: <4B1EA7F6.3090504@cornell.edu> <4B1F1424.9020105@cornell.edu> <4B1F5A63.3030509@swipnet.se> <4B1FBB8C.5090909@cornell.edu> <4B1FD098.4040400@cornell.edu> <4B1FF22D.8080800@swipnet.se> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="------------070106020105000809080908" X-Trace: ger.gmane.org 1260449460 14427 80.91.229.12 (10 Dec 2009 12:51:00 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 10 Dec 2009 12:51:00 +0000 (UTC) Cc: Stefan Monnier , emacs-devel@gnu.org To: =?ISO-8859-1?Q?Jan_Dj=E4rv?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Dec 10 13:50:52 2009 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1NIiTq-0002wA-Ke for ged-emacs-devel@m.gmane.org; Thu, 10 Dec 2009 13:50:51 +0100 Original-Received: from localhost ([127.0.0.1]:58679 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NIiTq-0001KD-11 for ged-emacs-devel@m.gmane.org; Thu, 10 Dec 2009 07:50:50 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NIhwR-0004yX-8E for emacs-devel@gnu.org; Thu, 10 Dec 2009 07:16:19 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NIhwL-0004uD-HA for emacs-devel@gnu.org; Thu, 10 Dec 2009 07:16:17 -0500 Original-Received: from [199.232.76.173] (port=41235 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NIhwL-0004tu-1D for emacs-devel@gnu.org; Thu, 10 Dec 2009 07:16:13 -0500 Original-Received: from granite1.mail.cornell.edu ([128.253.83.141]:51911 helo=authusersmtp.mail.cornell.edu) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1NIhwK-0002WX-VM for emacs-devel@gnu.org; Thu, 10 Dec 2009 07:16:13 -0500 Original-Received: from [127.0.0.1] (cpe-67-241-20-9.twcny.res.rr.com [67.241.20.9]) (authenticated bits=0) by authusersmtp.mail.cornell.edu (8.13.1/8.12.10) with ESMTP id nBACGA9M001679; Thu, 10 Dec 2009 07:16:11 -0500 (EST) User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) In-Reply-To: <4B1FF22D.8080800@swipnet.se> X-Antivirus: avast! (VPS 091210-0, 12/10/2009), Outbound message X-Antivirus-Status: Clean X-detected-operating-system: by monty-python.gnu.org: Solaris 9 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:118520 Archived-At: This is a multi-part message in MIME format. --------------070106020105000809080908 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by authusersmtp.mail.cornell.edu id nBACGA9M001679 On 12/9/2009 1:53 PM, Jan Dj=E4rv 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=20 >>>>>>>> memalign. >>>>>>>> + As malloc is not the Cygwin malloc, the Cygwin memalign always >>>>>>>> + returns ENOSYS. A workaround is to set G_SLICE=3Dalways-malloc= . */ >>>>>>>> +#define G_SLICE_ALWAYS_MALLOC >>>>>>> Why does Cygwin-Emacs use its own malloc rather than the system=20 >>>>>>> malloc? >>>>> Emacs prefers its own malloc when the system malloc doesn't have th= e >>>>> 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 comme= nt >>>> 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=20 >>> is to remove '#define G_SLICE_ALWAYS_MALLOC' from src/s/cygwin.h and=20 >>> instead #define SYSTEM_MALLOC. [You don't need to respond unless=20 >>> 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=20 >> window.o charset.o coding.o category.o ccl.o character.o chartab.o=20 >> cm.o term.o terminal.o xfaces.o emacs.o keyboard.o macros.o=20 >> keymap.o sysdep.o buffer.o filelock.o insdel.o marker.o minibuf.o=20 >> fileio.o dired.o filemode.o cmds.o casetab.o casefiddle.o indent.o=20 >> search.o regex.o undo.o alloc.o data.o doc.o editfns.o callint.o=20 >> eval.o floatfns.o fns.o font.o print.o lread.o syntax.o unexcw.o=20 >> bytecode.o process.o callproc.o region-cache.o sound.o atimer.o=20 >> doprnt.o strftime.o intervals.o textprop.o composite.o md5.o =20 >> sheap.o terminfo.o lastfile.o vm-limit.o getloadavg.o -lcurses= =20 >> -lg `gcc -print-libgcc-file-name` -lm -lc `gcc -print-libgcc-file-na= me` >> vm-limit.o:vm-limit.c:(.text+0x17): undefined reference to=20 >> `___after_morecore_hook' >> vm-limit.o:vm-limit.c:(.text+0x6c): undefined reference to `___morecor= e' >> >> I looked at the source code, and I can't see any place where Cygwin's=20 >> malloc.h is getting included. I don't know if that's the (only) probl= em. >> >> I also asked for help on the Cygwin list and got the following two=20 >> 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=3Dsbrk (or maybe one more undersc= ore >>> is needed) on the compile line for vm-limit.c. >> >>> why are you bothering to specify the system libs at all? You're usin= g >>> 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 bu= t >>> -lcurses out of that lot. You'll definitely break linking against=20 >>> the shared >>> libgcc by putting the static archive in the list of user libraries=20 >>> like that. >> >> I'm really in over my head at this point. If someone sees something I= =20 >> can do to fix this, I'll give it a try. Otherwise, maybe we should=20 >> just stick with the G_SLICE workaround for now. >> >=20 > You should be able to just comment out the lines in vm-limit.c, i.e.=20 > just put >=20 > void > memory_warnings (start, warnfun) > POINTER start; > void (*warnfun) (); > { > #ifndef CYGWIN > ... > #endif > } >=20 > so you can test it. OK, this enables the compilation to complete, but the resulting emacs crashes with a segfault, even with G_SLICE=3Dalways-malloc. And disablin= g 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=20 irrelevant for this issue, I still think it would be wise to follow it.=20 The attached patch accomplishes this. Could someone please apply it? Thanks. Ken --------------070106020105000809080908 Content-Type: text/plain; name="libs.patch" Content-Disposition: attachment; filename="libs.patch" Content-Transfer-Encoding: 7bit --- 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