From unknown Tue Jun 24 03:23:08 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#2867 <2867@debbugs.gnu.org> To: bug#2867 <2867@debbugs.gnu.org> Subject: Status: GNU Emacs 23.0.92 pretest fails to build for DJGPP target using SYSTEM_MALLOC Reply-To: bug#2867 <2867@debbugs.gnu.org> Date: Tue, 24 Jun 2025 10:23:08 +0000 retitle 2867 GNU Emacs 23.0.92 pretest fails to build for DJGPP target usin= g SYSTEM_MALLOC reassign 2867 emacs submitter 2867 Rugxulo severity 2867 normal thanks From rugxulo@gmail.com Thu Apr 2 13:10:21 2009 Received: (at submit) by emacsbugs.donarmstrong.com; 2 Apr 2009 20:10:21 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=0.2 required=4.0 tests=FOURLA,MDO_DATING14 autolearn=no version=3.2.5-bugs.debian.org_2005_01_02 Received: from lists.gnu.org (lists.gnu.org [199.232.76.165]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n32K9rGH000337 for ; Thu, 2 Apr 2009 13:09:54 -0700 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LpTEW-00052t-Nb for bug-gnu-emacs@gnu.org; Thu, 02 Apr 2009 16:09:52 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LpTES-00050Z-2R for bug-gnu-emacs@gnu.org; Thu, 02 Apr 2009 16:09:52 -0400 Received: from [199.232.76.173] (port=47129 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LpTER-00050V-PD for bug-gnu-emacs@gnu.org; Thu, 02 Apr 2009 16:09:47 -0400 Received: from mail-ew0-f160.google.com ([209.85.219.160]:40557) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LpTER-00043d-B3 for bug-gnu-emacs@gnu.org; Thu, 02 Apr 2009 16:09:47 -0400 Received: by ewy4 with SMTP id 4so755840ewy.42 for ; Thu, 02 Apr 2009 13:09:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=2Y8rn7eVQePCkJyoaZOS8e9X2138Qbz7jSkZD5NFi4c=; b=dBMgYXo8i49YrzW6xorQTAzpLSMtli6j2uDzFQni35RVRVCYu79wdklJEu6NODlITr fUXgqxloSjeu/5GL/5tYaIpIpMPHvSOFpewSjjJ4ae+HRmoiXvXQMn8Lf06SFxtiVCgB Gi1mqIqUg3R3lqctg0JkPSt0vy3Bi6s1R8VzI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=uZcB4I+bsJiPbsoFM0sJZlztfwM/QVMVQTHaiufaB3FX8leS9apB6s0aeU+snKm3da Wl/kaRA/vaPmdD7RLQli8qz+fF01I1TZN8/My7LwJMin2YwZfJSuwRGfVK4DuLtNq9tk tKHuJ0y24y7HBsEVIE1WzwcKe7Mm0/yoVASP8= MIME-Version: 1.0 Received: by 10.210.29.11 with SMTP id c11mr285977ebc.20.1238702985440; Thu, 02 Apr 2009 13:09:45 -0700 (PDT) Date: Thu, 2 Apr 2009 16:09:45 -0400 Message-ID: <93c172b50904021309g65556c73u89fb1e666cb5a0c7@mail.gmail.com> Subject: GNU Emacs 23.0.92 pretest fails to build for DJGPP target using SYSTEM_MALLOC From: Rugxulo To: bug-gnu-emacs@gnu.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) Hi, Unlike 22.3, you apparently can't build the latest GNU Emacs 23.0.92 pretest (43 MB .tar.gz download) if defining SYSTEM_MALLOC instead of default REL_ALLOC. This might sound a little weird / crazy, but Windows Vista doesn't report memory correctly and doesn't resize memory blocks like XP does. In other words, Vista is worse than XP in the NTVDM department. And I think Windows 2003 (and later 2008) shared the same kernels with Vista pre-SP1 and SP1, respectively. And Windows 7 will also share the same kernel. So this is a problem. With REL_ALLOC (default), it runs out of memory even when I know for a fact there is enough available (since other DJGPP apps can access it, yes I use the registry hack). It just doesn't work like it does on XP (which Eli Z. uses, so he never tests SYSTEM_MALLOC, apparently ... plus he says REL_ALLOC is more efficient). For 23 in CVS, Eli modified the CONFIG.BAT to support "--with-system-malloc", but there's a build error somewhere, even in the latest pretest download (23.0.92, I think it's called). Something about "_ret_lim_data": msdos.o w16select.o xmenu.o termcap.o tparam.o lastfile.o getloadavg.o -lg -lm dosfns.o:dosfns.c:(.text+0x663): undefined reference to `_ret_lim_data' collect2: ld returned 1 exit status make.exe[1]: *** [temacs.exe] Error 1 make.exe[1]: Leaving directory `c:/Armslurp/emacs-23.0.92/src' make.exe: *** [src] Error 2 I have successfully built 22.3 with DJGPP (on XP, though, since Vista is apparently buggy for building Emacs) with SYSTEM_MALLOC defined instead of REL_ALLOC in CONFIG.H. It works / loads 100% correctly with some "simple" test files (Matt Mahoney's enwik8 is 100 MB, I even successfully tried that file copied onto itself twice, e.g. 200 MB). Otherwise, it won't load the file ("Memory exhausted") even though I've set the DPMI limit much much higher than necessary. So, as you can see, SYSTEM_MALLOC is important to keep working (in my humble opinion). Unfortunately, Eli doesn't have enough time to test both. So any clues would be highly appreciated. WHY? The simple truth is that I don't want to babysit two different sets of Emacs (one DOS, one Win32) when both perform similar functions. In the "old days", you could expect the DOS app to run fine under Windows. Now, you can't take that bet. I know it's become a very very hostile place for DOS programmers these days, and Win32 (and Linux) take huge precedent, but I still feel like if I can get it to work in both, I'd rather do that. It's just simpler, more logical, easier, makes more sense. Am I wrong? At least until AMD64 is 100% ubiquitous, we have no reason to ignore V86 mode. (And heck, DOSEMU works in 64-bit too ... unlike Windows' NTVDM !) On a more practical note, I run Vista on my laptop and haven't backed it up yet (or resized the NTFS partition, ugh, to install a dual boot FreeDOS). I hate mess (oy)ing with installs that might break. But I can mostly get my FreeDOS-oriented programming done on it. (FreeDOS kernel is GPL, so no flames, please.) So it makes sense to build and test on the same host. And I have no other choice because I don't have any cross compilers (e.g. Cygwin to DJGPP). If you know of someone who has one, that would be nice, esp. for the day when AMD64 takes over the world. (I've built GCC a few times but it's always a hassle and doesn't always work. And Cygwin is another ball of wax, so my weak attempt didn't succeed. It seems someone should've done this already, but I know of no public downloads of such. Surely somebody else besides me would find it highly useful. But that's more a request for another place, probably.) From eliz@gnu.org Sat Apr 4 02:47:11 2009 Received: (at 2867-done) by emacsbugs.donarmstrong.com; 4 Apr 2009 09:47:11 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: * X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=1.0 required=4.0 tests=FVGT_m_MULTI_ODD,GMAIL, HAS_BUG_NUMBER,RCVD_IN_SBLXBL,RCVD_IN_SBLXBL_CBL autolearn=no version=3.2.5-bugs.debian.org_2005_01_02 Received: from mtaout6.012.net.il (mtaout6.012.net.il [84.95.2.16]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n349l6Mc007069 for <2867-done@emacsbugs.donarmstrong.com>; Sat, 4 Apr 2009 02:47:08 -0700 Received: from conversion-daemon.i-mtaout6.012.net.il by i-mtaout6.012.net.il (HyperSendmail v2007.08) id <0KHK00J00LPGES00@i-mtaout6.012.net.il> for 2867-done@emacsbugs.donarmstrong.com; Sat, 04 Apr 2009 12:47:00 +0300 (IDT) Received: from HOME-C4E4A596F7 ([84.228.139.199]) by i-mtaout6.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0KHK0046VLUB0M60@i-mtaout6.012.net.il>; Sat, 04 Apr 2009 12:47:00 +0300 (IDT) Date: Sat, 04 Apr 2009 12:44:56 +0300 From: Eli Zaretskii Subject: Re: bug#2867: GNU Emacs 23.0.92 pretest fails to build for DJGPP target using SYSTEM_MALLOC In-reply-to: <93c172b50904021309g65556c73u89fb1e666cb5a0c7@mail.gmail.com> X-012-Sender: halo1@inter.net.il To: Rugxulo , 2867-done@debbugs.gnu.org Reply-to: Eli Zaretskii Message-id: <83hc14da7b.fsf@gnu.org> References: <93c172b50904021309g65556c73u89fb1e666cb5a0c7@mail.gmail.com> > Date: Thu, 2 Apr 2009 16:09:45 -0400 > From: Rugxulo > Cc: > > For 23 in CVS, Eli modified the CONFIG.BAT to support > "--with-system-malloc", but there's a build error somewhere, even in > the latest pretest download (23.0.92, I think it's called). Something > about "_ret_lim_data": > > msdos.o w16select.o xmenu.o termcap.o tparam.o lastfile.o > getloadavg.o > -lg -lm > dosfns.o:dosfns.c:(.text+0x663): undefined reference to > `_ret_lim_data' > collect2: ld returned 1 exit status > make.exe[1]: *** [temacs.exe] Error 1 > make.exe[1]: Leaving directory `c:/Armslurp/emacs-23.0.92/src' > make.exe: *** [src] Error 2 Thanks for reporting this bug. Fixed with the following change: 2009-04-04 Eli Zaretskii * dosfns.c (system_process_attributes) [SYSTEM_MALLOC]: Don't call ret_lim_data. (Bug#2867) Index: src/dosfns.c =================================================================== RCS file: /cvsroot/emacs/emacs/src/dosfns.c,v retrieving revision 1.53 retrieving revision 1.54 diff -u -r1.53 -r1.54 --- src/dosfns.c 3 Jan 2009 15:02:30 -0000 1.53 +++ src/dosfns.c 4 Apr 2009 09:42:12 -0000 1.54 @@ -571,7 +571,9 @@ int i; Lisp_Object cmd_str, decoded_cmd, tem; double pmem; +#ifndef SYSTEM_MALLOC extern unsigned long ret_lim_data (); +#endif uid = getuid (); attrs = Fcons (Fcons (Qeuid, make_fixnum_or_float (uid)), attrs); @@ -604,8 +606,12 @@ make_fixnum_or_float ((unsigned long)sbrk(0)/1024)), attrs); attrs = Fcons (Fcons (Qetime, tem), attrs); +#ifndef SYSTEM_MALLOC + /* ret_lim_data is on vm-limit.c, which is not compiled in under + SYSTEM_MALLOC. */ pmem = (double)((unsigned long) sbrk (0)) / ret_lim_data () * 100.0; if (pmem > 100) +#endif pmem = 100; attrs = Fcons (Fcons (Qpmem, make_float (pmem)), attrs); /* Pass 1: Count how much storage we need. */ From unknown Tue Jun 24 03:23:08 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: $requester Subject: Internal Control Message-Id: bug archived. Date: Sat, 02 May 2009 14:24:07 +0000 User-Agent: Fakemail v42.6.9 # A New Hope # A log time ago, in a galaxy far, far away # something happened. # # Magically this resulted in the following # action being taken, but this fake control # message doesn't tell you why it happened # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator