Re: bootstrapping problems with native compiler

[Dave Love <d.love@dl.ac.uk>]

>>>>> "Jim" == Jim Wilson <wilson@cygnus.com> writes:

 Jim> The f77 runtime library depends on GCC_PARTS because it wants to
 Jim> compile-and-link code.  If this is just a runtime, then we
 Jim> should not need to actually link code.

Actually it wants to link and run too.  Its configuration needs to
check for non-ANSI sprintf (at least) and I don't know a way to do
that reliably other than with AC_TRY_RUN.  It certainly needs to be
able to do linking in configure to test for various library routines.

 Jim> If we do need to be able to link, then this will cause various
 Jim> problems (for instance it won't work for crosses), 

The released G77 is known basically to survive criss-cross builds.
(The sprintf test makes a pessimistic assumption if necessary.)  I've
probably omitted to document that that might be worth editing in most
cases of crosses.

 Jim> which will probably require moving the f77 runtime out of the
 Jim> gcc directory into its own directory.

The runtime is entirely isolated and configured separately in a
sub-directory of f/; it just depends on a working built (cross)
compiler for configuring.  However, it would be nice to be able to do
autoconf tests involving linking for the compiler as well as the
runtime from an f/configure.  In fact we used to hack that in from
config-lang.in.

(Some of this would be irrelevant if gcc provided an ANSI environment
by providing libiberty (?) type stuff where appropriate.  I don't know
how feasible that would be.)

I don't understand why C++ should stick stuff in libgcc anyhow -- why
isn't its runtime kept separate like objc and fortran?