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: Wed, 09 Dec 2009 14:29:26 -0500 Message-ID: <4B1FFA96.7000203@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: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1260387075 25060 80.91.229.12 (9 Dec 2009 19:31:15 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 9 Dec 2009 19:31:15 +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 Wed Dec 09 20:31:08 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 1NISFA-0006ke-7e for ged-emacs-devel@m.gmane.org; Wed, 09 Dec 2009 20:30:36 +0100 Original-Received: from localhost ([127.0.0.1]:54536 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NISFA-0002WO-0e for ged-emacs-devel@m.gmane.org; Wed, 09 Dec 2009 14:30:36 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NISED-00027n-Gn for emacs-devel@gnu.org; Wed, 09 Dec 2009 14:29:37 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NISE8-00025S-IJ for emacs-devel@gnu.org; Wed, 09 Dec 2009 14:29:36 -0500 Original-Received: from [199.232.76.173] (port=48367 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NISE8-00025K-Ai for emacs-devel@gnu.org; Wed, 09 Dec 2009 14:29:32 -0500 Original-Received: from granite1.mail.cornell.edu ([128.253.83.141]:58164 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 1NISE8-0003y2-3Z for emacs-devel@gnu.org; Wed, 09 Dec 2009 14:29:32 -0500 Original-Received: from [128.84.234.191] (markov.math.cornell.edu [128.84.234.191]) (authenticated bits=0) by authusersmtp.mail.cornell.edu (8.13.1/8.12.10) with ESMTP id nB9JTP4s017222 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 9 Dec 2009 14:29:25 -0500 (EST) User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) In-Reply-To: <4B1FF22D.8080800@swipnet.se> X-MIME-Autoconverted: from 8bit to quoted-printable by authusersmtp.mail.cornell.edu id nB9JTP4s017222 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:118474 Archived-At: 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, I'll try this when I get a chance. > The comments about static and dynamic libraries are in principle=20 > correct, but Emacs whats to do it like that for the sake of dumping. =20 > But my guess is that it may be redundant now, but since it works, nobod= y=20 > has tried to change it. There are a few platforms to test it on so why=20 > bother? Those comments came from Dave Korn, who is Cygwin's gcc maintainer. If=20 he's right that it breaks linking against the shared libgcc, I wonder if=20 that's been the problem all along. As I recall from the February 2007=20 thread, there was a suggestion that there were linking problems that=20 prevented Emacs's memalign from being called by glib. Is there a way I can disable linking against the static libgcc just to=20 see what happens? Ken