This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: A patch for g77spec.c



  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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]