[REQ] If the x86 people could do something about this...

[REQ] If the x86 people could do something about this...

[John Beppu]

        The problem I have with gcc's code generation for i386+
        regards the assigning of constants to variables in
        memory.  This constructor just sets a lot of things to 0.
        The assembly output of this constructor is a bit
        disappointing, though.  

.. C++ .................................................................

TextFile::TextFile()
{
    origBUF = NULL;
    lineDefLUT = NULL;
    eolnTYPE = EOLN_UNIX;
    accessMODE = xx_ACCESS;
    currentLINE = 0;
    lineQTY = 0;
    name[0] = 0;
    eolnStr[0] = 0x0d;
    eolnStr[1] = 0x0a;
    eolnStr[2] = 0x00;
    eolnStr[3] = 0x00;
}

        The following asm output was derived by using 
        
        "-O3 -fomit-frame-pointer -m486".  
        
        I would love it if gcc would be so kind as to put $0
        into a register.  The only way I found to coax gcc into
        putting $0 into a register was to compile without
        optimizations, and declare a variable of the form:

        register int blah = 0;

        Apparently the keyword "register" is ignored when
        compiling with -On (where n > 0).

.. x86 Assembly ........................................................

	.size	 _._8TextFile,.Lfe4-_._8TextFile
	.align 16
.globl __8TextFile
	.type	 __8TextFile,@function
__8TextFile:
	movl 4(%esp),%eax       ; movl $0,%ecx would be nice
	movl $0,16(%eax)        ; movl %ecx,16(%eax)
	movl $0,20(%eax)        ; movl %ecx,20(%eax)
	movl $0,156(%eax)       ; etc...
	movl $0,(%eax)
	movl $0,8(%eax)
	movl $0,4(%eax)
	movb $0,24(%eax)
	movb $13,152(%eax)
	movb $10,153(%eax)
	movb $0,154(%eax)
	movb $0,155(%eax)
	ret

        If this has already been dealt with in pgcc, great.  If
        not, I would really appreciate it if this were
        considered for modification.  It's such an easy
        optimization.  The example constructor would easily be
        twice as fast if not more if a register were to contain
        the constant $0, and used for the memory stores.

        Although this would require the use of one more register
        in a sparse register set, I believe this would be
        beneficial in more cases than detrimental.



  Thanks :)

  beppu@uci.edu .............................................................

Re: fixing the c++/f77 circular dependency

[Doug Evans]

   Date: Wed, 20 Aug 1997 15:18:31 -0700
   From: Jim Wilson <wilson@cygnus.com>

   I have thought of four possible solutions so far.
   1) Make all languages mandatory (eliminate LANGUAGES=X option).
   2) Move the C++ code out of libgcc.a.
   3) Move the f77-runtime out of the gcc directory.
   4) Put the f77-runtime in rest.encap instead of f77 LANGUAGES rule.

   The first option is probably too unpopular to consider further, though
   it would certainly simplify the Makefile.

You could add a --enable-lang=foo [or some such] option,
so while LANGUAGES=x is gone, the ability to only build a few
is not.

Re: egcs repository

[Jason Merrill]

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

>   In message <199708192228.PAA28350@yorick.cygnus.com>you write:
>> Seems to me that egcs should be one more directory down, so we can add
>> libstdc++ et al to the toplevel directory (and eventually move libF77
>> there, too).

> I've got no problems with that...

> Or maybe make gcc a subdir of egcs.  Who knows...

I don't feel strongly either way.  Does anyone else?  I'm figuring we can
just use the Cygnus toplevel directory stuff as seen in gdb et al.

Jason

Re: fixing the c++/f77 circular dependency

[Joel Sherrill]

On Sat, 30 Aug 1997, Stephen Williams wrote:

> My work largely involves freestanding C++. Please, libgcc needing things
> from the C library (and posix) is bad enough. Start bringing in libraries
> from all over the universe and ``main() { return 0; }'' will no longer
> fit on certain boards!-)

I have not tried lately to see what the smallest useful exeutable is but I
know it is sometimes surprising what gets pulled in.

> Also, this again gets back to the build cycle problems Joel keeps griping
> about (and I also experience) and extending it ot yet another library.

 I don't know if gripe is the right word.  I just did not want the
problem to get worse in the reorganization.  

The reorganization seems to be a big step in the right direction for
embedded targets. 

--joel

Re: fixing the c++/f77 circular dependency

[Stephen Williams]

jason@cygnus.com said:
> That may be.  The code currently in libgcc is the freestanding 
> library, which includes some code called by various language 
> constructs, and therefore needs to be linked in automatically.  I 
> don't want people to have to pull in libstdc++ to get RTTI support.

My work largely involves freestanding C++. Please, libgcc needing things
from the C library (and posix) is bad enough. Start bringing in libraries
from all over the universe and ``main() { return 0; }'' will no longer
fit on certain boards!-)

Also, this again gets back to the build cycle problems Joel keeps griping
about (and I also experience) and extending it ot yet another library.

-- 
Steve Williams
steve@icarus.com
steve@picturel.com

"The woods are lovely, dark and deep.  But I have promises to keep,
And lines to code before I sleep, And lines to code before I sleep."

Re: fixing the c++/f77 circular dependency

[Jim Wilson]

	So you do a 'make bootstrap'.  What's the problem?

See my initial message in this thread.  The problem incidentally has been
fixed.

	The Makefile has been fixed so LANGUAGES is passed to sub-makes, right?

Yes, but that is an unrelated problem.

Jim

Re: fixing the c++/f77 circular dependency

[Robert Lipe]

> > There exist hosts where the native compiler will build a subtly 
> > disfunctional cc1plus that therefore won't reliably compile the
> 
> So you do a 'make bootstrap'.  What's the problem?

In current snapshots, nothing.   Sorry if I was unclear.   

> The Makefile has been fixed so LANGUAGES is passed to sub-makes, right?

Yes.   But this characteristic has come and gone in that "other" branch 
with depressing frequency.   This is to reiterate the point that Jim made
that it's rather non-obvious and ill-understood.

RJL

Re: fixing the c++/f77 circular dependency

[Jim Wilson]

Incidentally, this particular problem is not one that needs to be fixed before
the initial release.  There is no point in trying to change the libgcc.a
build rules before the initial release, because there is too much risk that
this will break something.  There are many more important things that
we should be spending our time on at this time.

The circular dependency that was preventing egcs from building was important,
but that was fixed last week.

This scheme does seem more elegant than what we have now, and just taking
a quick look, I don't see anything obviously wrong with it.

The subdir_libgcc rule needs to use LANGUAGES, so that we build a subdirectory
libgcc only if that language is being built.

In order to actually work, this probably needs to be a lot more complicated
than what you have so far, because you haven't considered multilib yet.

Jim

Re: fixing the c++/f77 circular dependency

[Joe Buck]

I wrote:

> | During the build process, don't build a library named libgcc.a.  Instead,
> | build libgcc-c.a, libgcc-c++.a, libgcc-f.a (Fortran), etc.  At
> | installation time or just before, combine all of these libraries into one,
> | named libgcc.a.  The LANGUAGES variable determines which language-specific
> | libraries are combined to make libgcc.a.  Normally, gcc passes -lgcc to
> | the linker, but a flag can disable this, so that the compiler can be
> | bootstrapped with -lgcc-c instead.  We do want to wind up with a combined
> | libgcc.a so that multi-language programs work.

meissner@cygnus.com writes:

> No, installation time is too late.  I routinely test compilers in place
> without installing them (using ./xgcc -B./).

OK, it doesn't have to be installation time; each build can use LANGUAGES
to make libgcc.a, but the bootstrap process would not use this libgcc.a
to build the compiler with itself, it would only use libgcc-c.a.

I don't know enough about MULTILIB issues to comment there.  Maybe all
that is really needed is a temporary C-only library that is used in the
bootstrapping process and my solution is overkill.  But recent 2.8.0
snapshots have resulted in bogus libgcc.a files (that mysteriously fix
themselves if libgcc.a and constituent .o files are zapped and rebuilt)
so we need something simple and reliable.

Re: fixing the c++/f77 circular dependency

[Jason Merrill]

>>>>> Robert Lipe <robertl@dgii.com> writes:

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

So you do a 'make bootstrap'.  What's the problem?

The Makefile has been fixed so LANGUAGES is passed to sub-makes, right?

Jason

Re: fixing the c++/f77 circular dependency

[meissner]

| The following notion just occurred to me.  I'm not sure it's the cleanest
| thing in the world, but it does break the circle. The basic idea:
| 
| During the build process, don't build a library named libgcc.a.  Instead,
| build libgcc-c.a, libgcc-c++.a, libgcc-f.a (Fortran), etc.  At
| installation time or just before, combine all of these libraries into one,
| named libgcc.a.  The LANGUAGES variable determines which language-specific
| libraries are combined to make libgcc.a.  Normally, gcc passes -lgcc to
| the linker, but a flag can disable this, so that the compiler can be
| bootstrapped with -lgcc-c instead.  We do want to wind up with a combined
| libgcc.a so that multi-language programs work.

No, installation time is too late.  I routinely test compilers in place without
installing them (using ./xgcc -B./).

Re: fixing the c++/f77 circular dependency

[Robert Lipe]

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

Re: fixing the c++/f77 circular dependency

[David Edelsohn]

>>>>> Joe Buck writes:

Joe> During the build process, don't build a library named libgcc.a.  Instead,
Joe> build libgcc-c.a, libgcc-c++.a, libgcc-f.a (Fortran), etc.  At
Joe> installation time or just before, combine all of these libraries into one,
Joe> named libgcc.a.  The LANGUAGES variable determines which language-specific
Joe> libraries are combined to make libgcc.a.  Normally, gcc passes -lgcc to
Joe> the linker, but a flag can disable this, so that the compiler can be
Joe> bootstrapped with -lgcc-c instead.  We do want to wind up with a combined
Joe> libgcc.a so that multi-language programs work.

	Don't forget all of the MULTILIB variants.  This could get quite
involved and complicated to build libgcc-c, libgcc-c++, and libgcc-f for
various command-line flag cominations and then demux them during the
install.

David

Re: fixing the c++/f77 circular dependency

[H.J. Lu]

> 
> 	Could someone please tell me why we cannot put a target libgcc.a in
> 	cp/Makefile.in? It will resolve that problem. I am willing to
> 	write a patch if people think it is a good idea.
> 
> 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
> moving the rule to cp/Makefile.in does not solve this problem, because
> we still have libgcc.a dependencing on cc1plus.
> 

What I have in mind is

1. In top level Makefile:

libgcc.a: .... cc1 subdir_libgcc
	autolock.sh libgcc.a.lck $(AR) ..

subdir_libgcc: cc1
	for d in  ...
	do
		$(MAKE) libgcc.a
	done

2. In cp/Makefile, we have

libgcc.a: ../cc1 ../cc1plus
	.....
	autolock.sh ../libgcc.a.lck $(AR) ..


H.J.

Re: fixing the c++/f77 circular dependency

[Joe Buck]

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

The following notion just occurred to me.  I'm not sure it's the cleanest
thing in the world, but it does break the circle. The basic idea:

During the build process, don't build a library named libgcc.a.  Instead,
build libgcc-c.a, libgcc-c++.a, libgcc-f.a (Fortran), etc.  At
installation time or just before, combine all of these libraries into one,
named libgcc.a.  The LANGUAGES variable determines which language-specific
libraries are combined to make libgcc.a.  Normally, gcc passes -lgcc to
the linker, but a flag can disable this, so that the compiler can be
bootstrapped with -lgcc-c instead.  We do want to wind up with a combined
libgcc.a so that multi-language programs work.

Re: fixing the c++/f77 circular dependency

[Jim Wilson]

	Could someone please tell me why we cannot put a target libgcc.a in
	cp/Makefile.in? It will resolve that problem. I am willing to
	write a patch if people think it is a good idea.

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
moving the rule to cp/Makefile.in does not solve this problem, because
we still have libgcc.a dependencing on 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.

Jim

Re: fixing the c++/f77 circular dependency

[Olivier Galibert]

On Mon, Aug 25, 1997 at 11:32:36AM -0700, Jason Merrill wrote:
> The only other option would seem to be a third library, linked in along
> with libgcc.  Then the trick is insinuating it into the specs file.

This would be quite a pain if you want to link together C++ and fortran
object files...

  OG.

Re: fixing the c++/f77 circular dependency

[H.J. Lu]

> 
> >>>>> Jim Wilson <wilson@cygnus.com> writes:
> 
> > 	I'd like to see them in libgcc.a. It should not be hard to put
> > 	something in libgcc.a from cp/Makefile.
> 
> > I am not opposed to having C++ code in libgcc.a if it can be made to
> > work.  However, having already dealt with a number of problems resulting
> > from this, I am skeptical that it can be made to work cleanly.
> 
> That may be.  The code currently in libgcc is the freestanding library,
> which includes some code called by various language constructs, and
> therefore needs to be linked in automatically.  I don't want people to have
> to pull in libstdc++ to get RTTI support.
> 
> The only other option would seem to be a third library, linked in along
> with libgcc.  Then the trick is insinuating it into the specs file.
> 

Could someone please tell me why we cannot put a target libgcc.a in
cp/Makefile.in? It will resolve that problem. I am willing to
write a patch if people think it is a good idea.


-- 
H.J. Lu (hjl@gnu.ai.mit.edu)

Re: fixing the c++/f77 circular dependency

[Jason Merrill]

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

> 	I'd like to see them in libgcc.a. It should not be hard to put
> 	something in libgcc.a from cp/Makefile.

> I am not opposed to having C++ code in libgcc.a if it can be made to
> work.  However, having already dealt with a number of problems resulting
> from this, I am skeptical that it can be made to work cleanly.

That may be.  The code currently in libgcc is the freestanding library,
which includes some code called by various language constructs, and
therefore needs to be linked in automatically.  I don't want people to have
to pull in libstdc++ to get RTTI support.

The only other option would seem to be a third library, linked in along
with libgcc.  Then the trick is insinuating it into the specs file.

Jason

Re: fixing the c++/f77 circular dependency

[Jim Wilson]

	I'd like to see them in libgcc.a. It should not be hard to put
	something in libgcc.a from cp/Makefile.

I am not opposed to having C++ code in libgcc.a if it can be made to
work.  However, having already dealt with a number of problems resulting
from this, I am skeptical that it can be made to work cleanly.

Simply moving the rules into cp/Makefile does not itself fix the problem.
If we have a rule in Makefile that adds the C++ library created by cp/Makefile
to libgcc.a, then we still have the problem that libgcc.a depends on LANGUAGES
and/or cc1plus.  If we have a rule in cp/Makefile that adds stuff to libgcc.a,
then we have two different rules in two different Makefile writing to the
same file, which seems even worse.

Jim

Re: fixing the c++/f77 circular dependency

[H.J. Lu]

> 
> 	Why not fix it by moving the c++ part of libgcc.a into cp/Makefile?
> 
> That is one of the options I mentioned at the beginning of this discussion,
> and is still an open issue.
> 
> However, this does not fix the problem unless we move the c++ stuff out of
> libgcc.a and into a new library.  This means changing the c++ compiler to
> link in yet another library, and this isn't very desirable.  But now that
> we have added libstdc++ to the egcs distribution, this stuff could perhaps
> be moved into libstdc++.
> 

I'd like to see them in libgcc.a. It should not be hard to put
something in libgcc.a from cp/Makefile.

-- 
H.J. Lu (hjl@gnu.ai.mit.edu)

Re: fixing the c++/f77 circular dependency

[Mike Stump]

> Date: Fri, 22 Aug 1997 11:32:18 -0700
> From: Jim Wilson <wilson@cygnus.com>

> But now that we have added libstdc++ to the egcs distribution, this
> stuff could perhaps be moved into libstdc++.

That's where it started!  :-)

(One should not infer that I am against moving it from this message.)

Re: fixing the c++/f77 circular dependency

[Jim Wilson]

	Why not fix it by moving the c++ part of libgcc.a into cp/Makefile?

That is one of the options I mentioned at the beginning of this discussion,
and is still an open issue.

However, this does not fix the problem unless we move the c++ stuff out of
libgcc.a and into a new library.  This means changing the c++ compiler to
link in yet another library, and this isn't very desirable.  But now that
we have added libstdc++ to the egcs distribution, this stuff could perhaps
be moved into libstdc++.

Jim

Re: fixing the c++/f77 circular dependency

[Jim Wilson]

	But LANGUAGES is still desirable for bootstrapping, because if you compile
	with an inferior system compiler you only want to build the C compiler
	with it, and them build the rest with the just built gcc.

We do need a way to build only the C compiler in the first stage of a
bootstrap.  However, we do not have any particular need for LANGUAGES itself.
If we can find some other way to build only the C compiler, then we can get
rid of LANGUAGES.  For instance, it might be possible to have a `make all'
target that builds all languages, and a `make only_c' target that builds
only the C language stuff.

Jim

Re: fixing the c++/f77 circular dependency

[H.J. Lu]

> 
> Dave Love <d.love@dl.ac.uk> writes:
> 
> |>>>>>> "Doug" == Doug Evans <dje@cygnus.com> writes:
> |>  Doug> You could add a --enable-lang=foo [or some such] option,
> |>  Doug> so while LANGUAGES=x is gone, the ability to only build a few
> |>  Doug> is not.
> 
> |> I'd vote for that sort of thing.
> 
> But LANGUAGES is still desirable for bootstrapping, because if you compile
> with an inferior system compiler you only want to build the C compiler
> with it, and them build the rest with the just built gcc.
> 

Why not fix it by moving the c++ part of libgcc.a into cp/Makefile?

-- 
H.J. Lu (hjl@gnu.ai.mit.edu)

Re: fixing the c++/f77 circular dependency

[Andreas Schwab]

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

|>>>>>> "Doug" == Doug Evans <dje@cygnus.com> writes:
|>  Doug> You could add a --enable-lang=foo [or some such] option,
|>  Doug> so while LANGUAGES=x is gone, the ability to only build a few
|>  Doug> is not.

|> I'd vote for that sort of thing.

But LANGUAGES is still desirable for bootstrapping, because if you compile
with an inferior system compiler you only want to build the C compiler
with it, and them build the rest with the just built gcc.

Re: fixing the c++/f77 circular dependency

[Jim Wilson]

	 Jim> The fourth option is easy to implement.  The only downside I can see is
	 Jim> that the f77-runtime is now configured always, 

	It shoudn't be, and I didn't think it was in the vanilla version.
	Will try to look at it before absconding for the holiday weekend.

You are confusing the issues here a little.  The f77-runtime is being
configured all of the time because I changed the Makefile rule.  This was an
intentional change necessary to break the circular dependency.  It is not
a problem that you need to look at.

Jim

Re: fixing the c++/f77 circular dependency

[Dave Love]

>>>>> "Doug" == Doug Evans <dje@cygnus.com> writes:

 Doug> You could add a --enable-lang=foo [or some such] option,
 Doug> so while LANGUAGES=x is gone, the ability to only build a few
 Doug> is not.

I'd vote for that sort of thing.

Re: fixing the c++/f77 circular dependency

[Dave Love]

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

 Jim> The fourth option is easy to implement.  The only downside I can see is
 Jim> that the f77-runtime is now configured always, 

It shoudn't be, and I didn't think it was in the vanilla version.
Will try to look at it before absconding for the holiday weekend.

Re: fixing the c++/f77 circular dependency

[Andreas Schwab]

Doug Evans <dje@cygnus.com> writes:

|>    From: Alexandre Oliva <oliva@dcc.unicamp.br>
|>    Date: 21 Aug 1997 01:27:55 -0300

|>    > You could add a --enable-lang=foo [or some such] option,
|>    > so while LANGUAGES=x is gone, the ability to only build a few
|>    > is not.

|>    I'd rather have all languages enabled by default (as it is now), and
|>    configuring --without-g77, --without-g++ (is this a valid identifier,
|>    by the way?), etc would selectively disable them.  I could provide a
|>    patch for that, if you agree with it.

|> When I proposed and wrote a patch for --{with,without}-lang [over two
|> years ago] it was suggested that --{enable,disable} was more appropriate.

According to the autoconf manual --with[out]-PACKAGE should be used for
something optional that is external to the source package (eg,
--with-gnu-ld, --with-debugging-malloc).  --{enable,disable}-FEATURE is
for controling the inclusion of something which is part of the source
package, but optional (eg, --enable-haifa, --enable-maintainer-mode).

-- 
Andreas Schwab                                      "And now for something
schwab@issan.informatik.uni-dortmund.de              completely different"

Re: fixing the c++/f77 circular dependency

[Doug Evans]

   From: Alexandre Oliva <oliva@dcc.unicamp.br>
   Date: 21 Aug 1997 01:27:55 -0300

   > You could add a --enable-lang=foo [or some such] option,
   > so while LANGUAGES=x is gone, the ability to only build a few
   > is not.

   I'd rather have all languages enabled by default (as it is now), and
   configuring --without-g77, --without-g++ (is this a valid identifier,
   by the way?), etc would selectively disable them.  I could provide a
   patch for that, if you agree with it.

When I proposed and wrote a patch for --{with,without}-lang [over two
years ago] it was suggested that --{enable,disable} was more appropriate.

As for the behaviour, what's the default, etc. etc.
I don't have a strong opinion.  I realize it's reasonable
to want the default to be to install all languages.

Re: fixing the c++/f77 circular dependency

[Alexandre Oliva]

Doug Evans writes:

> You could add a --enable-lang=foo [or some such] option,
> so while LANGUAGES=x is gone, the ability to only build a few
> is not.

I'd rather have all languages enabled by default (as it is now), and
configuring --without-g77, --without-g++ (is this a valid identifier,
by the way?), etc would selectively disable them.  I could provide a
patch for that, if you agree with it.

-- 
Alexandre Oliva
mailto:oliva@dcc.unicamp.br mailto:aoliva@acm.org
Universidade Estadual de Campinas, SP, Brasil

fixing the c++/f77 circular dependency

[Jim Wilson]

I have thought of four possible solutions so far.
1) Make all languages mandatory (eliminate LANGUAGES=X option).
2) Move the C++ code out of libgcc.a.
3) Move the f77-runtime out of the gcc directory.
4) Put the f77-runtime in rest.encap instead of f77 LANGUAGES rule.

The first option is probably too unpopular to consider further, though
it would certainly simplify the Makefile.

The second and third options are non-trivial to implement, though we may
have to move in this direction in the long term.

The fourth option is easy to implement.  The only downside I can see is
that the f77-runtime is now configured always, though it is only built
if f77 is in LANGUAGES (the f77-runtime rule already checks for this).
This seems to be the best solution for the short term.

Anyone see any serious problem with this, or want to suggest alternative
solutions?

Without some kind of patch for this, I can't build egcs on the system on
my desk, so this is a rather important problem to me. :-)

I have a tentative patch, though it needs to be cleaned up a bit.

Index: Makefile.in
===================================================================
RCS file: /cvs/cvsfiles/egcs/Makefile.in,v
retrieving revision 1.7
diff -p -r1.7 Makefile.in
*** Makefile.in	1997/08/19 15:36:20	1.7
--- Makefile.in	1997/08/20 21:56:56
*************** LANG_MAKEFILES = @all_lang_makefiles@
*** 510,515 ****
--- 510,516 ----
  LANG_STAGESTUFF = @all_stagestuff@
  LANG_DIFF_EXCLUDES = @all_diff_excludes@
  LANG_LIB2FUNCS = @all_lib2funcs@
+ LANG_REST_ENCAP = @all_rest_encap@
  LANG_EXTRA_HEADERS = @all_headers@
  
  # Flags to pass to recursive makes.
*************** all.build: native xgcc $(EXTRA_PARTS) la
*** 718,724 ****
  # This is what must be made before installing GCC and converting libraries.
  start.encap: native xgcc specs $(LIBGCC1) xlimits.h lang.start.encap
  # These can't be made until after GCC can run.
! rest.encap: stmp-headers $(LIBGCC) $(STMP_FIXPROTO) $(EXTRA_PARTS) lang.rest.encap
  # This is what is made with the host's compiler
  # whether making a cross compiler or not.
  native: config.status config.h cpp $(LANGUAGES) \
--- 719,725 ----
  # This is what must be made before installing GCC and converting libraries.
  start.encap: native xgcc specs $(LIBGCC1) xlimits.h lang.start.encap
  # These can't be made until after GCC can run.
! rest.encap: stmp-headers $(LIBGCC) $(STMP_FIXPROTO) $(EXTRA_PARTS) $(LANG_REST_ENCAP)
  # This is what is made with the host's compiler
  # whether making a cross compiler or not.
  native: config.status config.h cpp $(LANGUAGES) \
Index: configure.in
===================================================================
RCS file: /cvs/cvsfiles/egcs/configure.in,v
retrieving revision 1.7
diff -p -r1.7 configure.in
*** configure.in	1997/08/19 21:09:17	1.7
--- configure.in	1997/08/20 21:17:53
*************** all_outputs=Makefile
*** 2924,2929 ****
--- 2925,2931 ----
  all_lang_makefiles=
  all_headers=
  all_lib2funcs=
+ all_rest_encap=
  
  # Add the language fragments.
  # Languages are added via two mechanisms.  Some information must be
*************** do
*** 2970,2975 ****
--- 2972,2978 ----
  			oldstyle_subdirs="$oldstyle_subdirs $s"
  		fi
  		all_lib2funcs="$all_lib2funcs $lib2funcs"
+ 		all_rest_encap="$all_rest_encap $rest_encap"
  	fi
  done
  
*************** AC_SUBST(all_lang_makefiles)
*** 3046,3051 ****
--- 3049,3055 ----
  AC_SUBST(all_stagestuff)
  AC_SUBST(all_diff_excludes)
  AC_SUBST(all_lib2funcs)
+ AC_SUBST(all_rest_encap)
  AC_SUBST(all_headers)
  AC_SUBST(extra_passes)
  AC_SUBST(extra_programs)
Index: f/Make-lang.in
===================================================================
RCS file: /cvs/cvsfiles/egcs/f/Make-lang.in,v
retrieving revision 1.4
diff -p -r1.4 Make-lang.in
*** Make-lang.in	1997/08/18 15:01:55	1.4
--- Make-lang.in	1997/08/20 21:18:15
*************** G77_CROSS_NAME = `t='$(program_transform
*** 96,102 ****
  # Note that it would be nice to move the dependency on g77
  # into the F77 rule, but that needs a little bit of work
  # to do the right thing within all.cross.
! F77 f77: f771 f77-runtime
  
  # Tell GNU make to ignore these if they exist.
  .PHONY: F77 f77 f77-runtime f77-runtime-unsafe f77.all.build f77.all.cross \
--- 96,102 ----
  # Note that it would be nice to move the dependency on g77
  # into the F77 rule, but that needs a little bit of work
  # to do the right thing within all.cross.
! F77 f77: f771
  
  # Tell GNU make to ignore these if they exist.
  .PHONY: F77 f77 f77-runtime f77-runtime-unsafe f77.all.build f77.all.cross \
Index: f/config-lang.in
===================================================================
RCS file: /cvs/cvsfiles/egcs/f/config-lang.in,v
retrieving revision 1.2
diff -p -r1.2 config-lang.in
*** config-lang.in	1997/08/12 17:12:05	1.2
--- config-lang.in	1997/08/20 21:18:15
***************
*** 25,30 ****
--- 25,31 ----
  # compilers	- value to add to $(COMPILERS)
  # stagestuff	- files to add to $(STAGESTUFF)
  # diff_excludes	- files to ignore when building diffs between two versions.
+ # rest_encap	- files to build after gcc can be used to link
  
  #if grep DECL_STATIC_CONSTRUCTOR $srcdir/tree.h >/dev/null; then
  #   if grep flag_move_all_movables $srcdir/toplev.c >/dev/null; then true
*************** case "$arguments" in
*** 58,63 ****
--- 59,66 ----
  esac
  
  diff_excludes="-x \"f/g77.info*\""
+ 
+ rest_encap="f77-runtime"
  
  # Create the runtime library directory tree if necessary.
  test -d f || mkdir f