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: Sun, 21 Jun 1998 23:02:20 -0600
- cc: hjl at lucon dot org, egcs-patches at cygnus dot com
- Reply-To: law at cygnus dot com
In message <199806220454.AAA26253@melange.gnu.org>you write:
> > In message <199806220424.AAA26163@melange.gnu.org>you write:
> > > >From the g77 documentation *in egcs*:
> >Then I would claim your documentation is in error as is your goal of
> >trying to provide version information for things external to the driver.
>
> Ok, but understand g77 has been doing this for, well, over a year now,
> so I'd like to understand why it's an error.
>
> >To get information about the backend and libraries you're going to
> >have to find another way. What you're doing is simply wrong.
>
> Okay, good, but *why*?
Because it doesn't work and I don't think you can make it work reliably.
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 :-)
> How would that expose a problem whereby *part* of an installation
> was overwritten by another installation of a different product,
> or different distribution? That's what I'm concerned about.
I'm concerned about
"g77 -v"
Giving errors. We got *tons* of complaints about that with the egcs-1.0 releases
(for g77 and g++). I was getting such errors before installing HJ's
patch. And given the lack of control over the linker & assembler I
don't see how you could make this work reliably.
I personally use it often to make sure I'm building with the expected
compiler. Particularly since I tend to have several on each system.
> >Note that you're trying to perform a link. This is *bad, bad bad*.
> >It is 100% wrong.
>
> Okay. Why? It has worked for a long time now.
?!? I've never seen it work correctly if you proceed to try and
link the program. Then again, I may be working on different platforms
and I've not been a g77 hacker :-)
> > > In short, that info *is* obtained, by, as you put it, "running the
> > > backend...and other crud". Dunno about running collect2 -- because
> > > I don't know whether that's an issue for g77.
> >It's an issue.
>
> Why?
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.
> I agree about the latter. There's only marginal usefulness in
> embedding strings in the driver -- that catches the case where
> the *source* tree is not "virginal" for a release when the build
> is done.
Right. No argument there.
> >Well, you're getting responses now. What you're trying to do is wrong.
>
> Okay. Why? Why is it so much more wrong than telling people to
> write a dummy Fortran program, compile it, and run it? Or is that
> wrong too?
Having them write a dummy program to test their installation is fine.
In fact, Cygnus has these kinds of sanity checks in its intallation
scripts.
But having "driver -v" report an error is not fine. If you can reliably
make the error go away, then I'm satisfied.
jeff