This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: A patch for g77spec.c
- To: Craig Burley <burley at gnu dot org>
- Subject: Re: A patch for g77spec.c
- From: Jeffrey A Law <law at cygnus dot com>
- Date: Mon, 22 Jun 1998 00:34:38 -0600
- cc: hjl at lucon dot org, egcs-patches at cygnus dot com
- Reply-To: law at cygnus dot com
In message <199806220620.CAA26587@melange.gnu.org>you write:
> >Because it doesn't work and I don't think you can make it work reliably.
>
> Okay, I'm confused, I thought I *had*. Then it turns out it doesn't
> work without -B (I assume) or installing it, which is not too
> surprising, I guess. Then somebody submits a patch that makes it
> stop working the way it's document and that's installed.
Hmmm, I thought I was working from an installed toolchain. Maybe not,
hard to remember what I'm doing from day to day.
> >If you can find a way to make it work reliably, then I'll withdraw the
> >"wrong" and we'll get on with our lives :-)
>
> Oh, okay, I thought you meant it was conceptually wrong.
Only in the sense that I don't think you can make it work :-) Though
I guess you could make a dummy program and have it get compiled.
> That's strange, because the same lack of control over the linker and
> assembler doesn't seem to inhibit "g77 foo.f" or "g77 -v foo.f" from
> working, correct? What exactly is the difference, besides "g77 -v"
> giving temporary names to the object and executable files?
Where does "main" come from during the link phase? Consider targets
which do things like "-u main" by default on the link line.
> Well, maybe there's something to that. How about if we *try* to
> enable it, i.e. without HJ's patch that disables the thing entirely,
> and see whether it'll work on various systems, and, as I said,
> have a bit of patience with it -- perhaps considering whether problems
> believed to be due to "it" are really telling us something else?
Trying now. Probably won't get it tested until tomorrow night since
it's getting late and I'll be busy as hell tomorrow during the day.
> >Because collect2 is going to be run on many targets. It's going to try
> >and link the non-existant program, then run nm on the result. That's
> >not going to work when the link fails.
>
> *What* non-existant program? "g77 -v" as I've architected it for
> some time has compiled, linked, executed, and then deleted a real,
> living, breathing program. That's how the library version info is
> produced. You can see this in the output of "g77 -v" for yourself;
> the assembler and linker are given *real* inputs and outputs as usual,
> just that they're temporary names.
Hmmm, maybe I jumped to a conclusion here. I saw the "undefined main"
error, which I assumed was because you were building a nonexistant
program. Maybe it was the contents of the real, living, breathing
dummy program that were the problem.
> The big change with g77 0.5.23 (gcc 2.8) and now egcs 1.1 is that
> there's no distinct g77 driver that invokes the gcc driver and
> also manages the temp-name/execution/removal stuff. Instead, the
> new lang-specs.h stuff persuades the g77-ish gcc driver to do that
> all by itself. There might be problems with that; if so, I'd like
> to find that out, since they'd probably exist with 0.5.23 as well
> (though nobody's reported anyway, AFAIK).
Actually, we had this in egcs-1.0.3 for the g77 driver.
jeff