dozen targets, and I'm getting it really fast.
This is with gmake 3.80, built from tarball under gcc 3.2 (same problem
when built under 2.96)
time make -f model_py_so.make
make: *** virtual memory exhausted. Stop.
0.020u 0.010s 0:00.52 5.7% 0+0k 0+0io 738pf+0w
It's hard to believe
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=detailitemitem_id=1517
--
---
Paul D. Smith [EMAIL
%% 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 archives I
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 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 downloading
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 just
%% 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:
%% 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
%% 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 anything
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 that
%% 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 perhaps
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
)?
Fabio Alemagna
Hello Fabio,
I get a message like this on Cray systems when running my make process in an
NQS (qsub) script with a prescribed amount of memory. Changing the amount of
memory alloted changes the point at which the error occurs.
My version of the make: *** virtual memory exhausted
13 matches
Mail list logo
