Re: bootstrapping problems with native compiler

Re: bootstrapping problems with native compiler

[meissner]

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

Re: bootstrapping problems with native compiler

[Jason Merrill]

>>>>> Dave Love <d.love@dl.ac.uk> writes:

> It seems wrong to me if you need to build c++ to get that in C.
> __constructor__ is useful for runtime configuration with g77 (and
> other languages?) but I hadn't realized the dependency, damn.

You don't need C++ for that.  Only the major runtime stuff is built with
g++ (RTTI and EH support code).

Jason

Re: bootstrapping problems with native compiler

[Dave Love]

>>>>> "meissner" == meissner  <meissner@cygnus.com> writes:

 meissner> Sounds like it won't work too well on Canadian Crosses
 meissner> where build, host, and target machines are all different.

I can only say that bug reports for cross-g77 have always been
welcome.  There has been a fix made in the development version for
cygwin defining `unix' AFAIR and there were some problems which
appeared to be due to bugs in cygwin which I think should be addressed
there.  (The term `criss-cross' was coined in g77 circles
independently on each side of the Atlantic as a less obscure
alternative to Canadian.)

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

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

It seems wrong to me if you need to build c++ to get that in C.
__constructor__ is useful for runtime configuration with g77 (and
other languages?) but I hadn't realized the dependency, damn.

Re: bootstrapping problems with native compiler

[Jim Wilson]

	The released G77 is known basically to survive criss-cross builds.
	(The sprintf test makes a pessimistic assumption if necessary.)

But it does so by making guesses if CC is a cross compiler that can't link.
This would not be necessary if the f77-runtime was a separate directory
from the compiler directory.

There is a very natural build order here: compiler, C library, F77 library.
Each one depends on everything that comes before it.  Unfortunately, because
the compiler and the F77 library are in the same directory, it is impossible
to build the C library in between them.  For an embedded cross, this matters
a lot, because the C library can not be built until after gcc, and hence
it will not exist when configuring the F77 library.  For a native, this
generally does not matter, but consider what happens if someone wants to
install a new version of gcc and GNU libc at the same time.  What order
do you compile them in?  The natural order is to build gcc first, and then
GNU libc.  However, when you are done, you have an installed f77-runtime that
was autoconfed against a library that no longer exists, and hence you may
need to build and install gcc again to get a working f77 runtime.  This
would not be a problem if the f77 runtime was moved out of the gcc directory,
as then we would be able to build them in the proper order.  (I'm assuming
here that we aren't using shared libraries, as that adds additional problems.)

I don't expect this to be fixed immediately, but it is something we should
seriously consider for the long term.

Some parts of libgcc2.c incidentally have the same problem, which is
worked around via the -Dinhibit_libc hackery.  This stuff should also
be in a directory parallel to a gcc directory instead of inside the gcc
directory, so that we can build it after the C library.

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

It was convenient.  C++ has always had some runtime stuff in libgcc.a, but
it was all written in C.  Recently, some C++ code was added in, and it is only
this C++ code that is causing problems.  Whether this C++ code should remain
in libgcc.a is an open issue.

Jim

Re: bootstrapping problems with native compiler

[Doug Evans]

   Date: Mon, 18 Aug 1997 18:48:07 -0400 (EDT)
   From: meissner@cygnus.com

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

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

Clearly using AC_TRY_RUN doesn't work too well for Canadian Cross builds,
but methinks Dave is saying an attempt has been made to handle them
[by choosing a default that works at least for the cases tried].

Re: bootstrapping problems with native compiler

[Dave Love]

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

Re: bootstrapping problems with native compiler

[Jim Wilson]

 Jeffrey> There's still some kind of circular dependency with
 Jeffrey> cplib2.txt that nobody's tracked down yet.

f77 depends on f77-runtime
f77-runtime depends on f/runtime/Makefile
f/runtime/Makefile depends on stmp-multilib (via $LIBGCC via $GCC_PARTS)
stmp-multilib depends on cplib2.txt
cplib2.txt depends on cplib2.ready
cplib2.ready depends on f77 (via $LANGUAGES)
circular dependence dropped

There are two curiousities here.

The f77 runtime library depends on GCC_PARTS because it wants to
compile-and-link code.  If this is just a runtime, then we should not need
to actually link code.  If we do need to be able to link, then this will cause
various problems (for instance it won't work for crosses), which will probably
require moving the f77 runtime out of the gcc directory into its own
directory.  I suspect it can be fixed by tweaking the f77 runtime autoconf
so that it doesn't try to link files.

The cplib2.ready file depends on LANGUAGES.  This is apparently an attempt
to get a dependence on cc1plus without actually mentioning anything C++
related unless C++ was in LANGUAGES.  Unfortunately, now that we have
more than one optional language, it means that some C++ stuff now ends up
with dependencies on some f77 stuff.

Jim

Re: bootstrapping problems with native compiler

[Dave Love]

>>>>> "Jeffrey" == Jeffrey A Law <law@hurl.cygnus.com> writes:

 Jeffrey> Did this happen during the stage2 build?  

I think so, but I lost the log.

 Jeffrey> There's still some kind of circular dependency with
 Jeffrey> cplib2.txt that nobody's tracked down yet.

Yes.  With gmake (and LANGUAGES passed down) I see:

[...]
if [ -f libgcc2.ready ] ; then \
	true; \
else \
	touch libgcc2.ready; \
fi
gmake[1]: Circular cplib2.ready <- f77 dependency dropped.
stage1/xgcc -Bstage1/  -DIN_GCC    -O -g  -DHAVE_CONFIG_H     -I. -I. -I./config -I./objc \

[...]

if [ -f libgcc2.ready ] ; then \
	true; \
else \
	touch libgcc2.ready; \
fi
gmake[3]: Circular stmp-multilib <- cplib2.txt dependency dropped.
top=`pwd`; \
src=`cd .; pwd`; \
  cd f/runtime; \
  CC="`case './xgcc -B./' in \
[...]

Then it dies after configuring the g77 runtime:

checking for getrusage... yes
updating cache ./config.cache
creating ./config.status
creating Makefile
creating config.h
config.h is unchanged
./xgcc -B./  -DIN_GCC    -O -g -I./include     -DNO_MEM -DNO_LONG_DOUBLE_IO -O0 -I. -c ./enquire.c
./enquire.c: In function `cprop':
./enquire.c:1387: warning: comparison is always 0 due to limited range of data type
./xgcc -B./  -DIN_GCC    -O -g -I./include   enquire.o -o enquire
ld: FATAL 9: I/O error (crtbegin.o): No such file or directory
collect2: ld returned 32 exit status
gmake[3]: *** [enquire] Error 1
gmake[3]: Leaving directory `/data1/scr1/fx/egcs-ss-970814'
gmake[2]: *** [stmp-multilib-sub] Error 2
gmake[2]: Leaving directory `/data1/scr1/fx/egcs-ss-970814'
gmake[1]: *** [stmp-multilib] Error 1
gmake[1]: Leaving directory `/data1/scr1/fx/egcs-ss-970814'
gmake: *** [bootstrap] Error 2
mscsv1 139%

Re: bootstrapping problems with native compiler

[Jeffrey A Law]

  In message <rzq4t8nlazh.fsf@djlvig.dl.ac.uk>you write:
  > >>>>> "Jim" == Jim Wilson <wilson@cygnus.com> writes:
  > 
  >  Jim> The problem here is that LANGUAGES is not passed on recursive
  >  Jim> invocations of make.  This causes a problem for any target (like
  >  Jim> irix6) with a multilib libgcc, because this is implemented via a
  >  Jim> recursive make.  
  > 
  > I passed LANGUAGES="$(LANGUAGES)" to all the $(MAKE)s in the top-level
  > Makefile.in and on an irix6.4 system with the native make (and having
  > forgotten to stop it picking up gcc as CC) it did a set of recursive
  > makes until running out of processes.
Did this happen during the stage2 build?  There's still some kind
of circular dependency with cplib2.txt that nobody's tracked down
yet.

Jeff

Re: bootstrapping problems with native compiler

[Dave Love]

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

 Jim> The problem here is that LANGUAGES is not passed on recursive
 Jim> invocations of make.  This causes a problem for any target (like
 Jim> irix6) with a multilib libgcc, because this is implemented via a
 Jim> recursive make.  

I passed LANGUAGES="$(LANGUAGES)" to all the $(MAKE)s in the top-level
Makefile.in and on an irix6.4 system with the native make (and having
forgotten to stop it picking up gcc as CC) it did a set of recursive
makes until running out of processes.

 Jim> Manfred Hollstein mailed a patch to the gcc2 developers that
 Jim> would fix this.

I checked the FSF version before complaining and couldn't see any
relevant changes there.  (Sorry I haven't been reading gcc2.)  If
someone can mail it to me I can see if it solves the problem on a
mighty, fairly-idle SGI.