A patch for g77spec.c
Mon Jun 22 08:53:00 GMT 1998
> 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.
Join Da Club. :)
> > >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 exactly what happens. `g77 -v' is turned by the driver into
something like `g77 -v -c -xf77-version /dev/null -xnone', in the
sense that the rest of the gcc driver sees that. `f77-version' is a
new "language" in egcs/gcc/f/lang-specs.h that preprocesses, compiles,
links, and then runs a complete program.
Where does the program come from? Well, cpp is given /dev/null as
both input and output, so it's not an issue there. (And, yes,
`-B./' is necessary when invoking `./g77' to invoke the not-yet-
installed cpp; otherwise it assumes it'll find it in the installed
location. Just verified that myself.)
Then, the `f77-version' "language" drives `f771' as usual *plus*
with a new option `-fnull-version' (which is not really new, but
it finally does something now).
That option tells f771 (the g77 front end) to just substitute a
dummy program. This is in egcs/gcc/f/lex.c:
if (ffe_is_null_version ())
/* Just substitute a "program" directly here. */
char line = " call g77__fvers;call g77__ivers;call g77__uvers;end"\;
column = 0;
for (p = &line; *p != '\0'; ++p)
column = ffelex_image_char_ (*p, column);
c = EOF;
goto have_line; /* :::::::::::::::::::: */
>From then on, it's basically business as usual, except of course that
the gcc/specs mechanism is used to use temporary files for the
output of f771, `as', `ld', and so on. That same mechanism takes care
of deleting the temporary files afterwards.
> > 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.
See above. Again, if `g77 -v' doesn't work as I've architected it,
I'd *really* like to know why/how that's true but `g77 -v foo.f' does
work. At least, in preference to just ripping out a useful `g77 -v'
> > 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.
Okay, remember to use `-B./' if you're invoking an uninstalled g77
in the current directory...same deal as if you wrote your own
dummy program and compiled that, as I pointed out earlier.
In fact, even `./xgcc -v' (which I assume is used instead of `./gcc -v'
as a special case in the test-suite stuff) reads the *installed*
specs file instead of ./specs. For all I know, this could cause
the wrong version to be run and/or reported...?
So I'd suggest using `-B./' *anytime* the current-directory copy of
the command driver is run...even for `-v' by itself.
> > *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.
No, it was almost certainly that `./g77 -v' was done instead of
`./g77 -B./ -v', or similar, so the `cpp' program was assumed to be
in $(libsubdir), but wasn't there since it hadn't been installed yet.
> > 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.
That's true, I should have conditionalized that part. Basically
egcs 1.0 is a "weird" g77 since it doesn't support --help,
--version, `g77 -v', and other things as g77 has long done. I'd
like to get egcs 1.1 back into sync with normal g77.
At least by doing this, maybe I'll inspire others to discuss and
maybe provide better ways of doing this overall. That is, gcc
itself should support --help and --version. Maybe `gcc -v' should
just say "No input files" as usual (though maybe with a short
version summary), same deal for the other drivers, and maybe
`gcc --version' should nicely report a short version summary as
outlined in the GNU coding standards, and maybe `gcc --version --verbose'
(aka `gcc --version -v') would then be needed to get the long
version `g77 -v' has been long reporting. These are just some
suggestions though; in the meantime, at least having egcs-g77
be compatible with official-g77 seems reasonable.
And, maybe maintainers of other drivers would be interested in
using g77spec.c instead of their current approach, since that'd
perhaps allow them to support multi-language compiles.
(E.g. `g77 foo.c bar.f' should now work.)
tq vm, (burley)
More information about the Gcc-patches