ARM native gcc-2.95.2

[David Korn]

>-----Original Message-----
>From: bkohlen@intrinsyc.com [ mailto:bkohlen@intrinsyc.com ]
>Sent: 09 March 2001 00:39

>OK, I used my existing arm-linux-gcc cross-compiler to build a native
>arm gcc.  When using the arm native gcc to compile a simple C (int
>main(void){return 0;}) program (or a complex one for that matter) it
>hangs for about 30 seconds, and then I repeatedly get the message:
>
>Out of memory: Killed process 553 (cpp)
>
>about 50-100 times.  I have 32M of RAM on the nfs-rooted board I am
>working with, don't see how it could actually be a problem.

  This is some variation of a well known bug that can arise because
of a faulty installation or problems with your path setting.

  The problem arises because the compiler calls out to a subprogram to do
the C pre-processing stage: this subprogram is called 'cpp' and generally
lives in $prefix/lib/gcc-lib/$target/$version.

  There is also a standalone version of the preprocessor provided, which 
is just a simplified variant of the gcc driver program that only calls
out to the pre-processor subprogram, and not to the usual compilation,
assembly and linking stages. 

  The trouble arises because this standalone is also called cpp.  So when
you are compiling a program with gcc, and the driver tries to call cpp,
just a little bad luck can mean it finds the standalone driver instead 
of the actual preprocessor subprogram.  gcc then calls that driver under
the misapprehension that it is the actual preprocessor.  And what's the
first thing that driver does?  It tries to call out to the preprocessor
subprogram!  And since all the gcc-drivers use the same path search
algorithm, it too finds the cpp-driver instead of the cpp-subprogram, and
calls it. 

  The result, as you have seen, is a huge stack of copies of 'cpp'
recursively calling out to itself.

  So, to diagnose the problem, let's start by having a look at

1) your PATH setting
2) the directory listings of $prefix/lib/gcc-lib/$target/$version and
   $prefix/bin
3) the output from "gcc -v -print-search-dirs"
4) If you still have the info available, the *exact* command lines you
   used to configure and build gcc.

  That should help us track it down.



        DaveK
-- 
 All your base are belong to us!


**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.

www.mimesweeper.com
**********************************************************************