* Re: toplevel 'make' in egcs trips on itself.
1997-10-29 16:34 ` toplevel 'make' in egcs trips on itself Robert Lipe
@ 1997-10-29 22:59 ` Robert Lipe
1997-10-30 9:05 ` Jeffrey A Law
0 siblings, 1 reply; 3+ messages in thread
From: Robert Lipe @ 1997-10-29 22:59 UTC (permalink / raw)
To: jpr, egcs
> At least the patch fixed your problem building info, no?
>
> > cc -DIN_GCC -g -o ../cc1plus \
> > call.o decl.o errfn.o expr.o pt.o sig.o typeck2.o class.o decl2.o
>
> This is a no-no. It's building cc1plus with the native compiler, which
> should never happen. This is a top-level makefile problem. I guess
> I do them out of order out of habit.
I've thought about this more and can't convince myself that this
would ever work well enough to be a good idea when the default
compiler is anything but a rather recent egcs/gcc. Can someone
that really understands the build mechanism here please listen while
I type through this aloud?
Given that the most frequent issues we see on the egcs lists are that
date X of egcs won't compile the C++ part of date X+Y (where Y can be
either positive or negative) libraries and all the Linux library and
installation environment skew problems, should the top level default
make all-gcc target be swapped from:
(cd gcc; $(MAKE) $(GCC_FLAGS_TO_PASS) all);
to
(cd gcc; $(MAKE) $(GCC_FLAGS_TO_PASS) bootstrap);
?
Is this just an characteristic of the gcc/Makefile that BOOT_LANGUAGES
is only obeyed during a 'make bootstrap'? Even though gcc/INSTALL
spells out how you should build gcc, the default thing that happens
when one does the perfectly logical thing of going to the top level
and typing 'make' doesn't do it this way, right? If we assume this
is the part to attack, we should work on this:
Right after cc1 is built, we rip along...
echo " toplev.o version.o tree.o print-tree.o stor-layout.o fold-const.o functio
n.o stmt.o except.o expr.o calls.o expmed.o explow.o optabs.o varasm.o rtl.o pri
nt-rtl.o rtlanal.o emit-rtl.o real.o regmove.o dbxout.o sdbout.o dwarfout.o dwar
f2out.o xcoffout.o bitmap.o alias.o integrate.o jump.o cse.o loop.o unroll.o flo
w.o stupid.o combine.o regclass.o local-alloc.o global.o reload.o reload1.o call
er-save.o insn-peep.o reorg.o sched.o final.o recog.o reg-stack.o insn-opinit.o
insn-recog.o insn-extract.o insn-output.o insn-emit.o profile.o insn-attrtab.o i
386.o getpwd.o convert.o bc-emit.o bc-optab.o" | sed -e 's, \([a-z0-9]\), ../\1
,g' -e 's/\.o/.o/g' >stamp-objlist
cd cp; make "AR_FLAGS=rc" "AR_FOR_TARGET=ar" "BISON=bison" "BISONFLAGS=" "CC=cc"
"CFLAGS=-g" "CLIB=-lPW" "GCC_FOR_TARGET=/home/play/negcs_/gcc/xgcc -B/home/play
/negcs_/gcc/" "LDFLAGS=" "LEX=flex" "LEXFLAGS=" "LN=ln" "LN_S=ln -s" "MAKEINFO=/
home/play/negcs_/texinfo/makeinfo/makeinfo " "MAKEINFOFLAGS=" "RANLIB_FOR_TARGET
=true" "RANLIB_TEST_FOR_TARGET=[ -f /usr/local/i586-pc-sco3.2v5.0.4/bin/ranlib ]
" "SHELL=/bin/sh" "STAGE_PREFIX=" "exeext=" "objext=.o" "exec_prefix=/usr/local"
"prefix=/usr/local" "tooldir=/usr/local/i586-pc-sco3.2v5.0.4" "bindir=/usr/loca
l/bin" "libsubdir=/usr/local/lib/gcc-lib/i586-pc-sco3.2v5.0.4/egcs-2.90.14" "CXX
_FOR_BUILD=c++" "CXXFLAGS=-g -O2" "CXX_FOR_TARGET=c++" ../cc1plus
cc -c -DIN_GCC -g -I. -I.. -I../../../egcs-971023/gcc/cp -I../../../egcs
-971023/gcc/cp/.. -I../../../egcs-971023/gcc/cp/../config ../../../egcs-971023/g
cc/cp/call.c
Once we cd to cp, should we change CC=cc to CC=GCC_FOR_TARGET?
I don't know if any of these approaches solve any problems or even if
the problems are real or just something that we need to better doc.
If this is worth fixing, and you can give me some guidance, I'll think
about it more and try to solve it. Right now, my feeling is that
we're violating the principle of least suprise: If you just type
'make' in the top level directory, you will get disfunctional tools
if you get them to build at all.
RJL
^ permalink raw reply [flat|nested] 3+ messages in thread