Re: bootstrapping problems with native compiler

[meissner@cygnus.com <meissner@cygnus.com>]

| >>>>> "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.

Sounds like it won't work too well on Canadian Crosses where build, host, and
target machines are all different.  For example at Cygnus, we build NT cross
compilers under random Unixes (for example, --host=i586-cygwin32,
--build=sparc-solaris2.5, --target=powerpc-eabi).

|  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.)

It can be done, its just a small matter of programming :-)  Of course, you do
have to build libiberty up to 3 times (once for build, once for host, and
possibly once for target).

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

Because GNU C supports static constructors and destructors as well with
__attribute__((__constructor__)).