aks@hub.ucsb.edu, , ks@somewhere (Alan Stebbens) (02/22/90)
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 93106aks@hub.ucsb.edu, , ks@somewhere (Alan Stebbens) (02/23/90)
Evans> I had sent larry a posible patch to this problem not very Evans> long after the last patch level was sent out (PL8). The Evans> basic idea is that the compiler set the symbol LANGUAGE_C Evans> if the filename ends in '.c'. This allows more then one Evans> language to use the include file(s), such as the assembler. Evans> Therefore, if you are reading from stdin, the constant is Evans> not set automajically. The work around is to invoke the Evans> pre-processor with a -DLANGUAGE_C in the case of MIPS based Evans> compilers. This takes care of some of the problems, but <signal.h> on the DS3100 also wants "mips" to be defined. Here is the line in question from /usr/include/signal.h: #if defined(vax) || (defined(mips) && defined(LANGUAGE_C)) Notice that both "mips" and "LANGUAGE_C" need to be defined. I can also imagine similar cases on other systems where the "standard" defines are supplied by "cc", and not by "cpp". Again, in my opinion, the simplest case is to try to let "cc" do the invocation of "cpp". The other alternative is to try and figure out the standard defines applied by the compiler, but not by the precompiler. This is doable on DECstations and Suns, but differently, and on other systems this may be impossible. Alan Stebbens <aks@hub.ucsb.edu>
evans@decvax.dec.com (02/23/90)
|Notice that both "mips" and "LANGUAGE_C" need to be defined. I |can also imagine similar cases on other systems where the |"standard" defines are supplied by "cc", and not by "cpp". Again, |in my opinion, the simplest case is to try to let "cc" do the |invocation of "cpp". I agree with this idea. At issue is the fact that the Configure mechanism wants to supply the input to the pre-processor via stdin, rather then through a file. If it were to be supplied in a file, like how all of the source code is supplied, then alot of the problem would go away. If you look through the Configure script, you will discover that it does know about 'cc -E' which should do the *right thing* on MIPS boxes, assuming the test file is called something like "foo.c". - Marc