Update of bug #16088 (project make):
Status:None => Duplicate
Open/Closed:Open => Closed
___
Follow-up Comment #1:
This is a duplicate o
URL:
<http://savannah.gnu.org/bugs/?func=detailitem&item_id=16088>
Summary: "make -r" causes "virtual memory exhausted" error
in make on AIX only
Project: make
Submitted by: None
Submi
%% "jagabandhu panda" <[EMAIL PROTECTED]> writes:
jp> While compiling an atmospheric model it says
jp> Entering the directory /directory path
jp> make[3] *** virtual memory exhausted. Stop
jp> Leaving the directory /directory path
jp> I came to know tha
Dear Sir,
While compiling an atmospheric model it says
Entering the directory /directory path
make[3] *** virtual memory exhausted. StopLeaving the directory /directory path
I came to know that this is a bug. I am using gnu-make. Please help me out to solve this problem.
regards
Paul Smith <[EMAIL PROTECTED]> wrote:
>Just a note: the 1989 ANSI C standard (adopted as the ISO C standard in
>1990) required that malloc(0) return a valid pointer, so any system that
>doesn't provide this capability is not even compliant with the most
>basic, bare minimum set of standards require
%% "John Jenniskens" <[EMAIL PROTECTED]> writes:
jj> This occurs on platforms where malloc(0) returns 0. I've found the
jj> error on AIX and on TRU64 (dec-osf) platforms.
Just a note: the 1989 ANSI C standard (adopted as the ISO C standard in
1990) required that malloc(0) return a valid point
Hello,
Given the following very small makefile:
all:
@echo TEST Succesfull!!
make-3.80 with --no-builtin-rules fails:
/home/huminf/johnj> make --no-builtin-rules -f test.mak
make: *** virtual memory exhausted. Stop.
This occurs on platforms where malloc(0) returns 0. I'
Hm. I can't reproduce this on either Linux or Solaris. There may be
other fixes that impact this.
Can you try the beta release? It's somewhat dated but it's got a lot
more fixes than 1517 in it:
http://paulandlesley.org/make/make-3.81beta1.tar.bz2
--
---
efile
(see attached file), it works on both platforms.
With
GNUMakefile1 (see attached file), it works with platform Linux, but not with
Solaris.
With Solaris and GNUmakefile1, I get a message
:
make: ***
virtual memory exhausted. Stop.
The difference
between the two makefiles (which con
This patch has fixed it. Thank you very much!!
-Original Message-
From: Paul Smith On Behalf Of Paul D.Smith
Sent: Tuesday, June 15, 2004 5:32 PM
To: Gregory Smith
Cc: [EMAIL PROTECTED]
Subject: Re: make: *** virtual memory exhausted. Stop.
Your problem is almost certainly an instance
Your problem is almost certainly an instance of an eval bug in 3.80.
See this report (and the included patch):
https://savannah.gnu.org/bugs/index.php?func=detailitem&item_id=1517
--
---
Paul D. Smith <[EMAIL PROTECT
I found a thread on bug-make, a year ago, about "*** virtual memory exhausted. Stop."
That involved 1000's of targets; it appeared that folks were taking it to be a
real case of memory overflow. The only response appeared to be that no leaks
were being found.
I am getting this mes
,01234567890123456789012345678901.idl))
---snap-
which, when evaluated (e.g. "make -r") with 3.80 results in a
*** virtual memory exhausted.
I traced the problem into the sources, which I saw the very 1st
time, and what I found is:
A call to variable_buffer_output results in
This bug has already been reported and fixed in the source, and the fix
will be included with the next release.
Look here for the bug report; there's a patch attached to it:
https://savannah.gnu.org/bugs/index.php?func=detailitem&item_id=1517
--
---
. "make -r") with 3.80 results in a
*** virtual memory exhausted.
I traced the problem into the sources, which I saw the very 1st
time, and what I found is:
A call to variable_buffer_output results in a xrealloc call when
appending the final '\0' while doing the eval. It seems
On Monday 06 October 2003 11:49, Peter A. Kerzum wrote:
> Excuse me for another silly question, but can you tell when could this
> error occure:
>
> virtual memory exhausted
When calling malloc(0) on some systems. See
http://savannah.gnu.org/bugs/?func=detailbug&bug_id=2888
Excuse me for another silly question, but can you tell when could this
error occure:
virtual memory exhausted
--
Best Regards,
Peter A. Kerzum
___
Bug-make mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-make
%% Fabio Alemagna <[EMAIL PROTECTED]> writes:
fa> I specified --host=m68k-amigaos, and configure added that prefix
fa> to all the tool's names, except, apparently, ar.
Weird. Both that it added that prefix to some, and that it didn't add
it to all.
This is an autoconf issue.
fa> Or perha
I ran your script and generated the directory structure. I then ran
make -R using the latest CVS source built with debugging but no
optimization, with valgrind. The results are:
$ valgrind /app/global/.builds/psmith/gmake/make/make -R
==20399== Memcheck, a.k.a. Valgrind, a memory error detector
On Mon, 23 Jun 2003, Paul D. Smith wrote:
> %% Fabio Alemagna <[EMAIL PROTECTED]> writes:
>
> fa> The first issue, is that even if it was cross compiling, it tried
> fa> to use the host's 'ar' command. I solved that by invoking
> fa> m68k-amigaos-ar by hand and letting make run again, however
%% Fabio Alemagna <[EMAIL PROTECTED]> writes:
fa> The first issue, is that even if it was cross compiling, it tried
fa> to use the host's 'ar' command. I solved that by invoking
fa> m68k-amigaos-ar by hand and letting make run again, however that
fa> should be fixed at the source.
If anyt
On Mon, 23 Jun 2003, Paul D. Smith wrote:
> %% Fabio Alemagna <[EMAIL PROTECTED]> writes:
>
> fa> Ok. Do you know if it still compiles on AmigaOS with ixemul (the
> fa> posix layer)? Well, I guess I can just try and see...
>
> No one has reported that it doesn't, but I'm not sure if anyone has
On 23 Jun 2003, Paul D. Smith wrote:
> %% Ted Stern <[EMAIL PROTECTED]> writes:
>
> ts> My version of the "make: *** virtual memory exhausted. Stop." bug
> ts> occurs from trying to include 1000's of files. It doesn't matter
> ts> how large
%% Fabio Alemagna <[EMAIL PROTECTED]> writes:
fa> Ok. Do you know if it still compiles on AmigaOS with ixemul (the
fa> posix layer)? Well, I guess I can just try and see...
No one has reported that it doesn't, but I'm not sure if anyone has
tried in a while. I don't have an Amiga system so I
On Mon, 23 Jun 2003, Paul D. Smith wrote:
> fa> the next make release to be expected?
>
> Sometime, before too long. I'm trying to get the MINGW and OS/2 support
> integrated for this release.
Ok. Do you know if it still compiles on AmigaOS with ixemul (the posix
layer)? Well, I guess I can jus
%% Fabio Alemagna <[EMAIL PROTECTED]> writes:
fa> On Mon, 23 Jun 2003, Paul D. Smith wrote:
>> It has already been fixed in the source tree, and the fix will be
>> included in the next version of GNU make. That version has not been
>> released yet.
fa> Yeah, I discovered that by downl
On Mon, 23 Jun 2003, Paul D. Smith wrote:
> It has already been fixed in the source tree, and the fix will be
> included in the next version of GNU make. That version has not been
> released yet.
Yeah, I discovered that by downloading the CVS version. When is the next
make release to be expected?
%% Fabio Alemagna <[EMAIL PROTECTED]> writes:
fa> That happens when using a construct like this:
fa> define function
fa> target: very long dependency list
fa> whatever
fa> endef
fa> and then passign that to $(eval) trough $(call). By reading the ml
fa> arch
%% Ted Stern <[EMAIL PROTECTED]> writes:
ts> My version of the "make: *** virtual memory exhausted. Stop." bug
ts> occurs from trying to include 1000's of files. It doesn't matter
ts> how large the files are --- what is important is the length of the
rror occurs.
My version of the "make: *** virtual memory exhausted. Stop." bug occurs from
trying to include 1000's of files. It doesn't matter how large the files are
--- what is important is the length of the files' pathnames. If I allow 128
mega words (1GB) for the qsu
That happens when using a construct like this:
define function
target: very long dependency list
whatever
endef
and then passign that to $(eval) trough $(call). By reading the ml
archives I got to know that this is a pretty old bug, which should have
supposedly been fixed
BB_5/_9/_8.mk' (search
path) (no ~ expansion)...
Reading makefile `/ptmp/stern/testmake/_4/_5/CCCC_9/_9.mk' (search
path) (no ~ expansion)...
make: *** virtual memory exhausted. Stop.
As you can see, the memory is exhausted when 5
Yes, building from CVS requires a lot of infrastructure. FYI, the
README.cvs file in the checked out source tree will tell you what you
need and what to do... you need autoconf, automake, and gettext, plus
the things that those tools need like Perl, GNU m4, etc.
--
--
On Tue, 17 Dec 2002, Paul D. Smith wrote:
> Hm. Have you applied the patch contained in Bug 1517?
>
> https://savannah.gnu.org/bugs/?func=detailbug&bug_id=1517&group_id=71
No. I'll try that.
I tried building from anonCVS but due to the lack of autoconf-etc. and other
GNU utilities (and who k
Hm. Have you applied the patch contained in Bug 1517?
https://savannah.gnu.org/bugs/?func=detailbug&bug_id=1517&group_id=71
--
---
Paul D. Smith <[EMAIL PROTECTED]> Find some GNU make tips at:
http://www.gn
eading makefile `/PROJSOURCE/obj/sv1/indep/s/seqgp.Fdeps' (search path) (don't
care) (no ~ expansion)...
Reading makefile `/PROJSOURCE/obj/sv1/indep/s/seqio.Fdeps' (search path) (don't
care) (no ~ expansion)...
make: *** virtual memory exhausted. Stop.
36 matches
Mail list logo
