Re: native cc re-used after 3-stage now

["Kaveh R. Ghazi" <ghazi at caip dot rutgers dot edu>]

 > From: "Kaveh R. Ghazi" <ghazi@caip.rutgers.edu>
 > 
 >  > From: Robert Lipe <robertl@sco.com>
 >  > 
 >  > After yesterday's commit (Thank you, Philipp) the gcc directory now does
 >  > successfully complete a three-stage from native.  But there is a catch.
 >  > 
 >  > The top level make bootstrap goes all through the build of GCC itself,
 >  > then when it decides to move along, it goes BACK into the GCC directory
 >  > and decides to rebuild cpp.  Of course, it does this with native cc
 >  > which wont' work becuase many of the objects have been build with the
 >  > generated cc.  As another possible hint, it seems to be rerunning
 >  > fixincludes on each pass now.
 >  > 
 >  > Does anyone recognize this?
 >  > make[2]: Entering directory `/home2/negcs/gcc'
 >  > /bin/cc  -DIN_GCC    -g  -DHAVE_CONFIG_H  -o cpp cppmain.o \
 >  > intl.o libcpp.a obstack.o alloca.o  ./intl/libintl.a     ../libiberty/libiberty.a
 >  > Undefined                       first referenced
 >  >  symbol                             in file
 >  > __divdi3                            libcpp.a(cppexp.o)
 >  > __udivdi3                           libcpp.a(cppexp.o)
 >  > __umoddi3                           libcpp.a(cppexp.o)
 >  > __moddi3                            libcpp.a(cppexp.o)
 >  > UX:ld: ERROR: cpp: fatal error: Symbol referencing errors. No output written to cpp
 > 
 > Having used native cc for stage1, I can confirm I am seeing the same
 > problem on sunos4 and solaris2.7.
 > 
 > Relinking cpp also happened to me on x86-linux, but because I had used
 > the system's gcc for stage1, it found the libgcc.a symbols in the
 > system copy instead of the CVS copy.
 > 
 > Of course that's still wrong, but the build proceeded so people using
 > gcc for stage1 may not notice it.
 > 
 > 		--Kaveh

I looked at this a bit.  For some reason, in stage2 and stage3 cpp is
being linked with libintl.a first and then libintl.a is rebuilt.  This
causes cpp's dependency to be out of date later on.

It might be related to HJ's intl parallel make problem:
http://gcc.gnu.org/ml/gcc-bugs/2000-06/msg00264.html

However I can't tell if the patch posted below for that is the right
approach.  Although I see an explanation of the symptoms in the
posting above, the patch below didn't explain how/why the proposed fix
addressed the problem.
http://gcc.gnu.org/ml/gcc-patches/2000-06/msg00297.html


		--Kaveh
--
Kaveh R. Ghazi			Engagement Manager / Project Services
ghazi@caip.rutgers.edu		Qwest Internet Solutions