--enable-c-cpplib build is broken

[Kaveh R. Ghazi]

 > From: Dave Brolley <brolley@cygnus.com>
 > 
 > Jeffrey A Law wrote:
 > 
 > >
 > >   >
 > >   > At this point I think I'll just get you to look at it.
 > > It helps a lot if you say more precisely how it broke.  Did cc1 or cc1plus
 > > not link?  If so, what symbols were undefined?  Or was the breakage more
 > > subtle?
 > 
 > You would think that I would know better..... :-)
 > 
 > It fails to link because of duplicate symbhols that are both in the cpplib
 > sources and in libiberty. I've attached the make output. I spent a bit of time
 > trying to fix the problem, but each fix reveled a new problem. Kaveh should do
 > a build configured with --enable-c-cpplib to reproduce the problems.
 > Dave

Dave,

	I just did an --enable-c-cpplib bootstrap and saw the link
failure.  I don't think it is failing because of duplicate symbols in
libiberty.a.  Those symbols are pretty much isolated in separate modules
and shouldn't be drawn in unless they are needed.  The issue appears to
be between an object file explicitly listed in the link line, and one of
the modules in libcpp.a.  That archive conflicts because its functions
are not isolated. 

	Eg, c-aux-info.o (explicitly requested to link cc1) defines
function `concat', it is also defined in prefix.o (which is part of
libcpp.a.)  While prefix.o wouldn't be drawn in because of the need
for `concat', it is pulled in for the other functions it has, and you
get a redundant `concat' as a result.  Something similar happens with
`xcalloc' between toplev.o and libcpp.a(cpplib.o).

	I'm testing a small patch to correct this.  But before
installing it I'd like to do some test bootstraps both with and
without --enable-c-cpplib.  Can you wait a day or two, or will it
interrupt your work?  (I can send you my untested patch if you want.)

		--Kaveh
--
Kaveh R. Ghazi			Engagement Manager / Project Services
ghazi@caip.rutgers.edu		Icon CMT Corp.