Re: toplevel 'make' in egcs trips on itself.

Re: toplevel 'make' in egcs trips on itself.

[Robert Lipe]

> | JP, this should circumvent the problem you had building info.   
> 
> Your claim was that this would build on OSR 5.0.4.  You didn't at first,
> mention that you were using GNU make, and possibly other "helpers".

Yeah, yeah.   Sue me. :-)

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.

Do a 'make bootstrap' from the top-level if your build cc is anything
but a gcc mutant.   I always just cd into gcc and do a 'make bootstrap'
there.

I'll cc this message to egcs to see how we can better head off the
(surely common) case of someone typing 'make' in the top level
and expecting everything to just build if their native cc isn't
gcc.

It's so obvious that I never thought of it...

>         cc -c  -DIN_GCC   -g  -W -Wall    -If -I./f -I. -I. -I./config f/bad.c -
> o f/bad.o
> error: Invalid subargument: -W-Wall

This is more of the same.  Using the native compiler to build
fortran libraries is not going to work.

RJL

Re: toplevel 'make' in egcs trips on itself.

[Robert Lipe]

> 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

Re: toplevel 'make' in egcs trips on itself.

[Jeffrey A Law]

  In message < 19971030005908.02875@dgii.com >you write:
  > 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?
Yup.

  > 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:
Actually it's the runtime libraries that are the issue -- the C++
front end (in theory) should be buildable by any old compiler.

We have a "bootstrap" target which is designed to deal with these
(and other) issues (like fortran).  The problem is it isn't doc'd
and it's not the way many folks are used to building gcc.

  > Is this just an characteristic of the gcc/Makefile that BOOT_LANGUAGES
  > is only obeyed during a 'make bootstrap'? 
Yes.

  > Once we cd to cp, should we change CC=cc to CC=GCC_FOR_TARGET?
No, because we might be building a cross compiler.

jeff