From mboxrd@z Thu Jan  1 00:00:00 1970
From: Robert Lipe <robertl@dgii.com>
To: egcs@cygnus.com
Subject: Re: fixing the c++/f77 circular dependency
Date: Mon, 25 Aug 1997 20:47:05 -0000
Message-ID: <9708252041.AA20624@rios1.watson.ibm.com>
In-reply-to: 199708252008.NAA18706@cygnus.com
X-SW-Source: 1997-08/0438.html
Message-ID: <19970825204705.AWb5GYcBT0hLk3gLpeGDqXXr6t8l9-fgT5frsedwj34@z>

Jim Wilson wrote:

> There is a serious dependency problem which has already been mentioned a few
> times.  If libgcc.a contains C++ code, then libgcc.a depends on cc1plus,
> which means we always build cc1plus even if it is not in languages.  Simply

Though I think this is well understood by the few people really in the
know, it's worth reiterating Jim's point for the rest.

There exist hosts where the native compiler will build a subtly 
disfunctional cc1plus that therefore won't reliably compile the
C++ code to go into libgcc.a.     Quoting INSTALL:

     C is the only language that is sure to work when you build with
     other non-GNU C compilers.  In addition, building anything but C
     at this stage is a waste of time.

So if you have libgcc that depends on cc1plus and you're compiling
with a "non-GNU C compiler" you're in a catch-22.

Yes, I realize one Right Thing To Do is to track down the problem 
in using the native compiler to build cc1plus.

> The existing rule for the C++ libgcc.a stuff uses contortions to try to
> avoid an explicit cc1plus dependency, but it is ugly, does not work reliably,
> and has been causing problems.

I feel that pain.  I'll confess that "internal compiler error" when
building tinfo.cc did not exactly lead me to the Makefile as a 
prime suspect.

RJL