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 <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*?

>You could embed the strings you need, or find some way to run the
>sub-tools *without* attempting to actually compile, assemble and
>link code.

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.

>  >  ld -m elf64alpha -G 8 -O1 -dynamic-linker /lib/ld-linux.so.2 @dots{}
>  >  /tmp/cca14485
>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.

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

>  > Yes, but installers shouldn't be required to first write a Fortran
>  > program; and, further, that info won't include the library version
>  > info that `g77 -v' does from an installed g77.
>Then you'll have to embed the strings into the g77 driver or find some
>other way to run the tools, but make absolutely sure they they do nothing
>except print version information.  I believe that is impossible since
>you don't have control over the assembler & linker for example.

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.  Though catching the case where the *installed* product
is not coherent catches that case as well, at least having the
strings incorporated at product build time into the driver would
allow us to easily distinguish the two situations.  In practice,
I haven't found that distinction to be useful, but I wouldn't
mind having it made in a more obvious manner.

>  > I believe, in every case, I've sent email to gcc2 explaining the need
>  > for more version info, support for --help, etc., and gotten little or
>  > no constructive response.  But that doesn't mean we didn't put the
>  > appropriate facilities in g77 to make things work.
>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?

        tq vm, (burley)


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