bug#2867: GNU Emacs 23.0.92 pretest fails to build for DJGPP target using SYSTEM_MALLOC

bug#2867: GNU Emacs 23.0.92 pretest fails to build for DJGPP target using SYSTEM_MALLOC

[Rugxulo]

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.)

bug#2867: marked as done (GNU Emacs 23.0.92 pretest fails to build for DJGPP target using SYSTEM_MALLOC)

[Emacs bug Tracking System]

[-- Attachment #1: Type: text/plain, Size: 947 bytes --]


Your message dated Sat, 04 Apr 2009 12:44:56 +0300
with message-id <83hc14da7b.fsf@gnu.org>
and subject line Re: bug#2867: GNU Emacs 23.0.92 pretest fails to build for DJGPP target	using SYSTEM_MALLOC
has caused the Emacs bug report #2867,
regarding GNU Emacs 23.0.92 pretest fails to build for DJGPP target using  SYSTEM_MALLOC
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@emacsbugs.donarmstrong.com
immediately.)


-- 
2867: http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=2867
Emacs Bug Tracking System
Contact owner@emacsbugs.donarmstrong.com with problems

[-- Attachment #2: Type: message/rfc822, Size: 6557 bytes --]

From: Rugxulo <rugxulo@gmail.com>
To: bug-gnu-emacs@gnu.org
Subject: GNU Emacs 23.0.92 pretest fails to build for DJGPP target using  SYSTEM_MALLOC
Date: Thu, 2 Apr 2009 16:09:45 -0400
Message-ID: <93c172b50904021309g65556c73u89fb1e666cb5a0c7@mail.gmail.com>

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.)




[-- Attachment #3: Type: message/rfc822, Size: 3593 bytes --]

From: Eli Zaretskii <eliz@gnu.org>
To: Rugxulo <rugxulo@gmail.com>, 2867-done@emacsbugs.donarmstrong.com
Subject: Re: bug#2867: GNU Emacs 23.0.92 pretest fails to build for DJGPP target	using SYSTEM_MALLOC
Date: Sat, 04 Apr 2009 12:44:56 +0300
Message-ID: <83hc14da7b.fsf@gnu.org>

> Date: Thu, 2 Apr 2009 16:09:45 -0400
> From: Rugxulo <rugxulo@gmail.com>
> 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  <eliz@gnu.org>

	* 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.  */