🚀 go-pugleaf

In article <CInK5E.3B1@cuug.ab.ca>, R. Day <rpjday@cuug.ab.ca> wrote:
>I wrote:
>
>: gcc-2.5.7
>: ---------
>
>:   The second problem I tracked down is a failure to build cc1plus.
>: I get "Virtual memory exhausted!".  My first thought was to shut off
>: stuff I didn't need (NFS, TCP/IP, ...) and try the make again.
>: This make completed, but unknown to me, it didn't build cc1plus
>: properly.  The first failure left around a damaged, non-runnable
>: cc1plus, which got installed.  This became apparent later when I
>: tried to build libg++-2.5.2.  To get around this, I stole cc1plus
>: from another pre-built distribution and installed it, but I would
>: prefer to have my build succeed cleanly.  Any hints on now to avoid
>: running out of virtual memory?  Nothing I do seems to help.
>
>OK, I beat this.  I just removed the "-g" CFLAGS option from the make
>involving stage1.
>
>  $ make CC="stage1/xgcc -Bstage1/" CFLAGS="-O"    (No "-g" flag anymore.)
>
>  Was this a bad decision?  It solved the problem, so it can't be
>all bad.  Comments?

I have been having basically the same results.  I was using GNU make, 
SCO R3.2v4.2 and GCC v2.5.7.  I could "make LANGUAGES=c" without problem.
When it tried to build C++ it failed during the link stage with a 
"line number record count overflow" (or something like that) pointing at
reload1.o.  Assuming we had an overrun problem, the SCO linker not being
able to handle this many records, I rebuilt using the GNU Linker and
assembler.  This got me past this problem but it then failed with a
"Virtual memory exhausted" message.  After a RTFM session I followed 
instructions and relinked with the GNU malloc package.  This solved this
problem.  Unfortunately on the next build the GNU linker gave a "virtual
memory exhausted" message.

I believe the problem is that there are too many debug infos for it.


-- 
Vance Shipley, vances@xenitec.on.ca