Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!aplcen!haven!uvaarpa!mmdf
From: aks@hub.ucsb.edu, , ks@somewhere (Alan Stebbens)
Newsgroups: comp.lang.perl
Subject: Problems with DS3100 'cc' defines .vs. /usr/lib/cpp
Message-ID: <2722@uvaarpa.virginia.edu>
Date: 22 Feb 90 01:31:37 GMT
Sender: mmdf@uvaarpa.virginia.edu
Reply-To: aks@hub.ucsb.edu
Lines: 28

In compiling Perl for the DS3100, I came across an anomaly:

When Configure determines that /usr/bin/cpp is the way to feed
standard input to the preprocessor, it doesn't take into account
that when 'cc' invokes cpp, it also passes along some standard
defines, such as "mips", "LANGUAGE_C", "unix", "bsd4_2", "ultrix",
and some others.  By invoking cpp directly, these defines are
lost, and unfortunately, there are include files, such as
<signal.h>, which depend on some of these missing defines.
Because of this dependency, and their omission, Configure
incorrectly determines that signal() returns "int" rather than
"void". 

In my opinion, although this may be less "efficient" during the
configuration process, if the first guess of "cc -E" using stdin
fails, then the second guess should be to try the little shell
script sequence of "cat $1 /tmp/$$.c; cc -E /tmp/$$.c; rm -f
/tmp/$$.c".  This would catch the cases, as on the DS3100, where
the compiler does the predefines, and not the precompiler.
If this second attempt fails, then try an explicit invocation of
"cpp".

Does this make sense?

Alan Stebbens        <aks@hub.ucsb.edu>             (805) 961-3221
     Center for Computational Sciences and Engineering (CCSE)
          University of California, Santa Barbara (UCSB)
           3111 Engineering I, Santa Barbara, CA 93106