shep@ALLSPICE.LCS.MIT.EDU (12/31/88)
[ I sent this message yesterday, but it got returned, and I didn't see
it show up where I read bug-gcc, so I am sending it again. ]
I just picked up gcc-1.32 and started bootstraping it on my vax
running mostly 4.3bsd unix.
Gcc-1.32 seems to be looking in /usr/local/include for things like
"#include <stdio.h>". I believe this is new with this version. I
don't know why, but when someone here installed some sort of C++
compiler here (without sources) they put a bunch of C++ .h files in
/usr/local/include and needless to say, gcc finding C++ versions of
things like stdio.h there is confusing things badly. So, I did
"mv /usr/local/include{,.C++}" which solved the problem for me for now,
but undoubtably broke the C++ compiler (which fortunately isn't being
used now).
I had to add a line "MAKE = make" to the Makefile in order to make
"make bootstrap" work. I've had to do this for the last few releases
of gcc, and I believe I reported it a while ago.
"make bootstrap" is not restartable. (If something goes wrong after
the "make stage1" has completed, then typing "make bootstrap" causes a
lot of work to be done again.) This has bothered me for a while, and
I think I now know a way to at least allow it to be started manually
on a later stage:
bootstrap: all force
$(MAKE) stage1
$(MAKE) bootstrap2
bootstrap2:
$(MAKE) CC="stage1/gcc -Bstage1/" CFLAGS="-O $(CFLAGS)"
$(MAKE) stage2
$(MAKE) bootstrap3
bootstrap3:
$(MAKE) CC="stage2/gcc -Bstage2/" CFLAGS="-O $(CFLAGS)"
-Tim Shepard
<shep@ptt.lcs.mit.edu>brooks@maddog.llnl.gov (Eugene Brooks) (01/01/89)
In article <8812301920.AA18876@PTT.LCS.MIT.EDU> shep@ALLSPICE.LCS.MIT.EDU writes: >Gcc-1.32 seems to be looking in /usr/local/include for things like >"#include <stdio.h>". I believe this is new with this version. I >don't know why, but when someone here installed some sort of C++ >compiler here (without sources) they put a bunch of C++ .h files in >/usr/local/include and needless to say, gcc finding C++ versions of >things like stdio.h there is confusing things badly. So, I did >"mv /usr/local/include{,.C++}" which solved the problem for me for now, >but undoubtably broke the C++ compiler (which fortunately isn't being >used now). I guess I am partially responsible for this, the header directories /usr/include and /usr/local/include should be searched in the same order that the loader searches the corresponding library directories /usr/lib and /usr/local/lib. The following patch to cccp.c will provide more reasonable behavior, and behavior which will not break in the event that strange stuff has been deposited in /usr/local/include. Having the C++ headers in /usr/local/include instead of a C++ specific directory is a bad idea, however. These should be in /usr/include/CC or /usr/local/include/CC. *** /tmp/,RCSt1a03022 Sat Dec 31 16:17:57 1988 --- cccp.c Sat Dec 31 16:16:42 1988 *************** *** 315,322 { #ifndef VMS { &include_defaults[1], GCC_INCLUDE_DIR }, ! { &include_defaults[2], "/usr/local/include" }, ! { 0, "/usr/include" } #else { &include_defaults[1], "GNU_CC_INCLUDE:" }, /* GNU includes */ { &include_defaults[2], "SYS$SYSROOT:[SYSLIB.]" }, /* VAX-11 "C" includes */ --- 315,322 ----- { #ifndef VMS { &include_defaults[1], GCC_INCLUDE_DIR }, ! { &include_defaults[2], "/usr/include" }, ! { 0, "/usr/local/include" } #else { &include_defaults[1], "GNU_CC_INCLUDE:" }, /* GNU includes */ { &include_defaults[2], "SYS$SYSROOT:[SYSLIB.]" }, /* VAX-11 "C" includes */