Mail Archives: djgpp/1998/04/17/08:41:53
"Paul Derbyshire" <pderbysh AT usa DOT net> wrote:
> There's no love lost between RHIDE and the PGCC 1.0.1 cc1plus.exe. Sometimes
> when launched in RHIDE, this cc1plus will inexplicably choke and complain about
> "virtual memory" being "exhausted", even though there're 23 physical megabytes
> free and 62 virtual. When run from the command prompt, cc1plus works fine, even
> though it has exactly the same memory available (since RHIDE, like all
> DJGPP-compiled software, swaps itself out entirely when it launches a subtask).
> This means I have to enter long commandlines manually, capture errors with
> redir and manually look them up in the sourcefiles, instead of being able to
> handily track down the error by simply selecting it in the RHIDE output window.
>
> It can't possibly be malloc failure, since there's no way in hell cc1plus is
> using over 62 megs in compiling! Besides, even if it were using 62 megs it
> would have the exact same problem at the command prompt, which it does not.
>
> So what is wrong with PGCC? What other circumstances will make it emit that
> error message? Environment space perhaps? RHIDE will fill its environment and
> that of any subtask with $RHIDE_COMPILE_FLAGS and so forth, so that could be
> it, except I just don't see why cc1plus would use environment space as internal
> storage.
Well, it seems to be a problem of gcc in general, perhaps this particular cc1
is even worst. The FACT is that gcc is sensitive to PHYSICAL memory, don't ask
me way or how, I really don't understand the effect. For some tasks gcc really
needs PHYSICAL memory and all the virtual memory in the world doesn't help a
bit.
A good example in my system is that W95 some times eats enogh physical memory
to make fail my compiling, under plain DOS the same is when RHIDE uses 2Mb more
than normally (for example: too much editor opened and InfView with a huge info
file, or debug info loaded in memory).
gcc 2.8.0 seems to be less sensitive to this problem.
I don't understand why it happends because gcc uses malloc (or I'm wrong in it,
could it use sbrk() for something?). Perhaps is some fragmentation effect, in
this case:
Does anybody tried to link gcc with the DJGPP alpha malloc?
Greetings, SET
------------------------------------ 0 --------------------------------
Visit my home page: http://set-soft.home.ml.org/
or
http://www.geocities.com/SiliconValley/Vista/6552/
Salvador Eduardo Tropea (SET). (Electronics Engineer)
Alternative e-mail: set-soft AT usa DOT net set AT computer DOT org
ICQ: 2951574
Address: Curapaligue 2124, Caseros, 3 de Febrero
Buenos Aires, (1678), ARGENTINA
TE: +(541) 759 0013
- Raw text -