Re: Idea: Eliminate libf2c/f2c.h installation from g77 entirely?

Re: Idea: Eliminate libf2c/f2c.h installation from g77 entirely?

[N8TM]

In a message dated 4/18/98 2:28:54 PM Pacific Daylight Time, burley@gnu.org
writes:

<< egcs@cygnus.com, g77-alpha@gnu.org >>

it might be time to eliminate from g77 any and all
attempts to "help" the sysadmin by installing the libf2c.a and
f2c.h files 

my $.02

I don't know anyone who links with libf2c nowadays other than by invoking g77,
so for practical purposes libf2c belongs to g77.  I use f2c, the source code
processor, as an alternate to g77 sometimes, for example to try out processor-
dependent ways of doing things.

I haven't seen any great problems with the libf2c way of doing library calls,
and I can imagine much worse ways, having in front of me daily the example of
HPUX.  It might be nice to have a way to invoke the gcc macro facility, but it
would also contribute to non-portability.  I can see what to me are
significant improvements in parts of the library, without intentionally
departing from the current f2c conventions.  I'm planning to make up a .diff
file of my versions compared to egcs 1.0.2

Re: Idea: Eliminate libf2c/f2c.h installation from g77 entirely?

[Craig Burley]

>I haven't seen any great problems with the libf2c way of doing library calls,
>and I can imagine much worse ways, having in front of me daily the example of
>HPUX.

I'm not quite sure what that refers to.  My problems with the libf2c
interface include things like not returning COMPLEX arguments in an
efficient way, not putting version numbers and other signature info
on procedures (e.g. a prefix like "libf2c_") to avoid clashes across
separately maintained libraries, etc.  The usual stuff people who've
"been there, done that" in the world of library design whine about
when encountering somebody else's library.

>It might be nice to have a way to invoke the gcc macro facility, but it
>would also contribute to non-portability.

What does that mean?  Do you mean you want to call cpplib, the
preprocessor?  I think that can be done, though it's still
experimental.  Not sure what that, or any other interpretation
I can think of, has to do with libf2c.a and f2c.h.

>I can see what to me are
>significant improvements in parts of the library, without intentionally
>departing from the current f2c conventions.  I'm planning to make up a .diff
>file of my versions compared to egcs 1.0.2

Your math work is definitely something I'd like to start putting
into a libg77.a when that gets built.  Actually I'd like to make
g77 follow what I believe is the Sun convention of getting all
the computations to work as precisely as possible across the entire
domain (turns out g77 doesn't do this with complex multiply, for
example), secondarily make them work fast, tertiarially offer
even faster versions for limited domains (at least I'm guessing
Sun offers this in appropriate situations).  I don't expect
much progress on my end in this area until well into next year,
given my current plans, but that's okay since I'm no math/algorithm
expert.

In the meantime I'm very hesitant about making algorithmic
differences in numerical routines between g77's libf2c and
netlib's.  Even if some things got more accurate, that could
be perceived as introducing bugs in some codes that expected
the previous behaviors (this is Fortran, after all ;-).  So
I think introducing a libg77.a along with other code-generation
changes explicitly advertised as "we're going to try very hard
to get everything right, then everything fast, then let you get
limited-domain answers even faster" is the best time to make
algorithmic changes.

        tq vm, (burley)

Re: Idea: Eliminate libf2c/f2c.h installation from g77 entirely?

[Craig Burley]

>HPUX Fortran implements libU77 calls by requiring the use of a special pre-
>processor which mangles the names of the +U77 calls implemented in that
>release, plus linking with the +U77 library.  Any functions not implemented in
>that release link with C library functions of the same name, resulting in run-
>time error when a function expecting call by value is called by reference.  So
>I don't see a useful way of including compilers like that in g77's bag of
>compatibility options.

I'm not worrying about that sort of compatibility, at least not for
a very long time!  Sounds like HP took perhaps a kludgey route around
the libU77 problem, which I think we solved best in g77 by "just"
making libU77 procedures into intrinsics, so the compiler knows what
it's doing.  Not that that wasn't a lot of work, but it's made things
as easy as reasonably possible for users -- either they don't have to
edit their code, or they (probably) have to fix it so it is more
portable or continues using the kludgey use-name-as-ordinary-external
approach.

>Nor would I see any reason to use the Sun argument passing convention as it
>was in the old days, where all arguments have to be passed in integer
>registers, even for in-line compiled functions.

No, I'm not thinking about that either.  If we design libg77, we just
don't want to limit ourselves to the calling conventions that libf2c
uses, which are limiting *beyond* whatever ABI is in place.  (That is,
libf2c's interface assumes the basic C ABI, then constrains it further
by, e.g., assuming only some early-generation K&R C conventions can
be safely used.)  libg77 should be more flexible, even to the point
of allowing alternate interfaces for frequently used (at run time)
procedures depending on the optimization needs of the local code, and
use appropriate naming conventions to disambiguate all this, though
that's not required for the first implementations (but the *architecture*
of the library, e.g. the naming scheme, needs to thoughtfully
accommodate it).

>In a message dated 4/19/98 1:40:14 AM Pacific Daylight Time, burley@gnu.org
>writes:
>>In the meantime I'm very hesitant about making algorithmic
>>differences in numerical routines between g77's libf2c and
>>netlib's.  Even if some things got more accurate, that could
>>be perceived as introducing bugs in some codes that expected
>>the previous behaviors (this is Fortran, after all ;-). 
>
>I find it hard to believe that any g77 code depends on the particular level of
>accuracy resulting from some version of glibc plus the libf2c code.  At the
>very least, such code would not be portable between platforms supporting g77
>nor to compilers other than g77.  Actually, libf2c is nearly as accurate as
>any Fortran in single precision complex, being far better than HPUX or Lahey,
>for example.  

I'm pretty sure people *do*, usually unwittingly, depend to some degree
on *inaccuracy* of their compiler.  At least, based on the bug reports
we get, it seems that way.

However, I think it's reasonable for you to consider submitting
patches to improve numerics to egcs for inclusion in a future release,
so everybody can look at them -- at least, assuming enough relevant
people are testing g77 in the egcs snapshots on their code.

>>the Sun convention of getting all
>>the computations to work as precisely as possible across the entire
>>domain (turns out g77 doesn't do this with complex multiply, for
>>example)
>
>Well, I haven't had much access to Suns lately.  I did check at one time to
>see that SGI and HP didn't take any precautions with complex multiply, not
>even promoting single precision complex multiply to use double for
>intermediate operations, which would prevent any damage by under or over-flow
>and assure full accuracy.  I do think that g77 has gone well beyond being a
>compiler primarily oriented toward Sun, or making other brands act like a Sun.
>The day is long gone when Sun made the best Fortran machines.

I get that impression, too, but I'd like g77 to pick and choose the
"best" features among the various implementations and offer them
in a continuing portable compiler.  And maybe Digital Fortran takes
the same approach regarding accuracy, but I know some Sun people have
told me (directly and via c.l.f) that accuracy over complete input
domain is a basic "principle" they stick to, and that seems like a
worthwhile objective for g77 to me.

This seems to be about as much discussion of long-distant futures
issues I should engage in for now, being so busy.  Please don't worry
if I don't respond further, at least right now, but I'm definitely
still interested (and expect others will be too) in further input
on these issues.  That is, I'll read them now, but maybe not respond
to them for some time, so I can keep getting work done.  (I'm getting
*very* used to putting things off.  This August will mark the end of
the fourth year we've lived in our new condo.  I haven't finished
unpacking my stuff yet.  ;-)

I should note that the g77 docs have some relevant background
materials on most of the above issues.

        tq vm, (burley)

Re: Idea: Eliminate libf2c/f2c.h installation from g77 entirely?

[N8TM]

HPUX Fortran implements libU77 calls by requiring the use of a special pre-
processor which mangles the names of the +U77 calls implemented in that
release, plus linking with the +U77 library.  Any functions not implemented in
that release link with C library functions of the same name, resulting in run-
time error when a function expecting call by value is called by reference.  So
I don't see a useful way of including compilers like that in g77's bag of
compatibility options.

Nor would I see any reason to use the Sun argument passing convention as it
was in the old days, where all arguments have to be passed in integer
registers, even for in-line compiled functions.

In a message dated 4/19/98 1:40:14 AM Pacific Daylight Time, burley@gnu.org
writes:
In the meantime I'm very hesitant about making algorithmic
differences in numerical routines between g77's libf2c and
netlib's.  Even if some things got more accurate, that could
be perceived as introducing bugs in some codes that expected
the previous behaviors (this is Fortran, after all ;-). 

I find it hard to believe that any g77 code depends on the particular level of
accuracy resulting from some version of glibc plus the libf2c code.  At the
very least, such code would not be portable between platforms supporting g77
nor to compilers other than g77.  Actually, libf2c is nearly as accurate as
any Fortran in single precision complex, being far better than HPUX or Lahey,
for example.  

the Sun convention of getting all
the computations to work as precisely as possible across the entire
domain (turns out g77 doesn't do this with complex multiply, for
example)

Well, I haven't had much access to Suns lately.  I did check at one time to
see that SGI and HP didn't take any precautions with complex multiply, not
even promoting single precision complex multiply to use double for
intermediate operations, which would prevent any damage by under or over-flow
and assure full accuracy.  I do think that g77 has gone well beyond being a
compiler primarily oriented toward Sun, or making other brands act like a Sun.
The day is long gone when Sun made the best Fortran machines.

Re: Idea: Eliminate libf2c/f2c.h installation from g77 entirely?

[Craig Burley]

>I don't understand this discussion (again).  libf2c.a and f2c.h were
>installed outside the gcc tree to avoid an f2c installation screwing
>g77, not to help f2c.  What's changed to avoid this?  I don't think
>anything has on my GNU box.  (gcc will prefer stuff in /usr/local.)

Maybe you understand the situation better than I do, which could
easily explain your not understanding my email!

"gcc foo.o -lf2c -lm" (aka "g77 foo.o") needs to pull in libf2c.a.
It seem like you're saying it'll prefer, e.g., /usr/local/lib/libf2c.a
over /usr/local/lib/gcc-lib/$machine/$version/libf2c.a.  The latter
certainly should be "correct" in the near-vanilla cases; the former
might not be if it's not installed by g77 or if, after being
installed, is overwritten by installing (or re-installing) f2c.

If that's the case, then my proposal is indeed wrong for libf2c.a.
(It still works for f2c.h, since g77 doesn't depend on that post-
installation, but I'd like to fix the whole problem in a
consistent way.)

>I think the way to avoid conflicts is renaming of the g77 version.
>Linking f2c-generated C would still work as well by doing the job with
>the `g77' program if that would still compile other languages than
>Fortran.  (That's what I do with the non-egcs version when I test f2c
>stuff.)

Okay, I'm all for this option, in fact I came close to proposing it
before deciding to offer what seemed like a less radical approach.

>(The correct) f2c.h is necessary or, IMHO should be used, if you write
>g77-callable C.

Right, I'm still in favor of "installing" it as
/usr/local/lib/gcc-lib/$machine/$version/f2c.h, so anyone
can copy it out or whatever afterwards.  Don't see any need
to stop that practice.

>AFAIR at one time what happened about installing was controlled by a
>configure option, but it was tricky to implement and fragile in the
>gcc 2.7 framework.

Apparently!  As an experiment I was trying yesterday to fix this
in a mythical 0.5.22.1.  After getting the basics, I abandoned it,
because I felt I'd learned enough by poring over the relevant stuff
without trying to get it correct (given that I'm not planning to
release a 0.5.22.1).

>Sorry I missed the lossage with the current f2c (non-)installation.  

That's okay, if people don't complain something's broken, it's
pretty amazing if we ever notice it at all.  In this case, two
different bug reports came in within a few weeks of each other,
one against g77 0.5.22's confusions, the other against egcs
overwriting libf2c.a even when installing a cross-compiler.

I'd like to amend my proposal now to include renaming `libf2c.a' to
`libg2c.a', to further reduce the chances of conflict (e.g. the
situation where installing f2c results in g77 linking to the "new",
but possibly older and not properly configured, libf2c.a, instead
of the one built specifically for that version of g77).

That is, I propose that g77 0.5.23 (based on gcc 2.8) and egcs 1.1,
when released, install libf2c.a as libg2c.a *only* in the gcc-lib
heirarchy, and f2c.h as the same name *only* in that heirarchy as well.

Any objections?

Also, is it really certain that gcc's invocation of ld defaults
to searching the system libraries before its gcc-lib/ ones?  If that's
certainly *not* the case, then we don't really need to rename the
library.

        tq vm, (burley)

P.S. I've got a good-enough memory to know that there's almost nothing
I'm proposing above, or previously, that hasn't already been suggested
to me or ask for, by g77 users for the most part, in the past!  Thanks
to those who made these suggestions!

Re: Idea: Eliminate libf2c/f2c.h installation from g77 entirely?

[N8TM]

In a message dated 4/19/98 1:25:45 AM Pacific Daylight Time, burley@gnu.org
writes:

 problems with the libf2c
interface include things like not returning COMPLEX arguments in an
efficient way


I've done quite a bit of performance testing on the rs/6000 version  and the
way it's currently done isn't a signficant drag, as long as we avoid excessive
depth of calls, such as use of f__cabs.

More answers later, no time now!

Re: Idea: Eliminate libf2c/f2c.h installation from g77 entirely?

[Dave Love]

I don't understand this discussion (again).  libf2c.a and f2c.h were
installed outside the gcc tree to avoid an f2c installation screwing
g77, not to help f2c.  What's changed to avoid this?  I don't think
anything has on my GNU box.  (gcc will prefer stuff in /usr/local.)

I think the way to avoid conflicts is renaming of the g77 version.
Linking f2c-generated C would still work as well by doing the job with
the `g77' program if that would still compile other languages than
Fortran.  (That's what I do with the non-egcs version when I test f2c
stuff.)

(The correct) f2c.h is necessary or, IMHO should be used, if you write
g77-callable C.

AFAIR at one time what happened about installing was controlled by a
configure option, but it was tricky to implement and fragile in the
gcc 2.7 framework.

Sorry I missed the lossage with the current f2c (non-)installation.  

Re: Idea: Eliminate libf2c/f2c.h installation from g77 entirely?

[Craig Burley]

>  In message < 199804182125.RAA23699@melange.gnu.org >you write:
>  > I'm thinking it might be time to eliminate from g77 any and all
>  > attempts to "help" the sysadmin by installing the libf2c.a and
>  > f2c.h files somewhere, which is currently done so that f2c users
>  > "automatically" use the same files as used by g77, making successful
>  > linking of executables combining objects generated by both g77 and
>  > f2c more likely.
>I'm all for it :-)  We quite a few folks complaining about the
>installation procedure writing outside of $prefix on the egcs
>lists.
>
>Of course, we might get complaints in the other direction after
>we make the change.

Yeah, but, in the end, it's easier to tell people to copy the
two files they want to wherever they want them than to tell them
to restore the two system files "make install" on egcs overwrote.  :)

>However, I still feel removing the extra copies of f2c.h and
>libf2c.a is the right thing to do.

I agree.  In looking at g77 0.5.22 even more closely, I discovered
the whole installation of these two files was sufficiently screwed
up that it probably never did install them into the system directories
anyway, despite all the attempts to check whether doing so was okay.

If I'm right about that, given that there have been basically no
complaints, I'd say not having g77 installation overwrite the system
copies of libf2c.a and f2c.h is something nobody is likely to object
to (at least for their own purposes).

>  >   -  If f2c isn't being used, the only need for f2c.h (which g77
>  >      generates its copy of via its configuration process from f2c.h.in,
>  >      which in turn is just a modified copy of netlib's f2c's f2c.h)
>  >      is when building g77's copy of libf2c.  There is no need to install
>  >      this f2c.h anywhere; it's almost like an object file in this
>  >      respect, in that, once the build is completed, it isn't needed.
>I thought we needed to make sure that someone building a translated
>file picked up the right f2c.h.

The first phrase on that item applies to the whole item, though that
wasn't clear -- *only* f2c users need f2c.h sitting around somewhere
(except that g77 needs it during its build of libf2c.a, as explained).

>  >   -  If f2c isn't being used, as long as g77 prefers "its" copy of libf2c.a
>  >      (e.g. the one in $prefix/lib/gcc-lib/$machine/$version) over the one
>  >      in the system's (/usr/lib) library, libf2c.a need not be installed
>  >      anywhere else.  That is, it's really no different than the cc1,
>  >      cc1plus, f771, and specs files, AFAIK.
>I'm pretty sure that the libf2c.a from libsubdir will be preferred,
>but we should double check.

This is the only mystery to me at this point.  I've not yet really
explored the vast underworld of UNIX (and other systems') linking,
search lists, and so on.  (Except PRIMOS, where I pretty much
wrote the book.  :)

>  > Only a sysadmin who cares about g77 and f2c inter-operability will be
>  > interested in what we do, and I believe that it'll be safer and more
>  > robust, overall, to have g77 just "do its job" and not futz with bits
>  > and pieces of f2c installation, leaving it to the sysadmin to do that,
>  > as would be described in the g77 docs.
>I'd tend to agree.  If we want to make their life easier we might
>consider a configure time option to install f2c.h & libf2c.a
>in /usr/local/..., regardless of the $prefix option.

That's sort of like what g77 pretended, but apparently failed, to
offer.  (Maybe it worked for some old releases, but I don't think
it does for those circa 0.5.22.)

I suggest we wait until people ask for it, then ask them why they
can't just write up and distribute a simple script that, given the
f2c and g77 configurations they point it to, update the former
with the latter's libf2c.a and f2c.h, instead of re-infecting
g77 (via egcs or whatever) with non-GNU configuration info.

Pretty soon it'd also be nice to add the use of libtool or
what-not to g77 so libf2c.a can be built as a shared library.
Maybe that involves the whole multi-libbing thing, which I've
yet to explore, but maybe not.

In any case, the simpler the procedure, the easier it is to
introduce new stuff like making a shared library, multi-libbing,
and so on to libf2c.a (or maybe we'll rename it libg77.a soon).

>I also get the feeling that f2c is becoming less and less important
>as g77 continues to move forward and gain wider acceptance.  I can't
>think of a reason to use f2c over g77 on the two platforms where I
>do most of my work (hppa & x86).

Array bounds checking comes to mind.  Yes, I'd like to knock this
one off someday soon.  It'll probably take only a little research
and time to do an f2c-equivalent job of it; much more to do a
Digital-Fortran-style job.

        tq vm, (burley)

Re: Idea: Eliminate libf2c/f2c.h installation from g77 entirely?

[Jeffrey A Law]

  In message < 199804182125.RAA23699@melange.gnu.org >you write:
  > I'm thinking it might be time to eliminate from g77 any and all
  > attempts to "help" the sysadmin by installing the libf2c.a and
  > f2c.h files somewhere, which is currently done so that f2c users
  > "automatically" use the same files as used by g77, making successful
  > linking of executables combining objects generated by both g77 and
  > f2c more likely.
I'm all for it :-)  We quite a few folks complaining about the
installation procedure writing outside of $prefix on the egcs
lists.

Of course, we might get complaints in the other direction after
we make the change.

However, I still feel removing the extra copies of f2c.h and
libf2c.a is the right thing to do.

  > (A short summary of the overall issues: g77 currently uses libf2c,
  > f2c's run-time library, for it's own run-time needs.  It ships with
  > a patched version of libf2c, but we've avoided creating gratuitous
  > incompatibilities in the interface.  That, combined with appropriate
  > effort in g77, allows users to pretty much pick and choose which
  > Fortran modules they compile with g77 and which with f2c, link
  > the objects together, and have things actually work, even including
  > starting I/O in a g77-compiled module and continuing it in an
  > f2c-compiled one.)
Yup.  And I've even taken advantage of this at one point, though
I don't remember why :-)

  >   -  If f2c isn't being used, the only need for f2c.h (which g77
  >      generates its copy of via its configuration process from f2c.h.in,
  >      which in turn is just a modified copy of netlib's f2c's f2c.h)
  >      is when building g77's copy of libf2c.  There is no need to install
  >      this f2c.h anywhere; it's almost like an object file in this
  >      respect, in that, once the build is completed, it isn't needed.
I thought we needed to make sure that someone building a translated
file picked up the right f2c.h.

  >   -  If f2c isn't being used, as long as g77 prefers "its" copy of libf2c.a
  >      (e.g. the one in $prefix/lib/gcc-lib/$machine/$version) over the one
  >      in the system's (/usr/lib) library, libf2c.a need not be installed
  >      anywhere else.  That is, it's really no different than the cc1,
  >      cc1plus, f771, and specs files, AFAIK.
I'm pretty sure that the libf2c.a from libsubdir will be preferred,
but we should double check.



  > Only a sysadmin who cares about g77 and f2c inter-operability will be
  > interested in what we do, and I believe that it'll be safer and more
  > robust, overall, to have g77 just "do its job" and not futz with bits
  > and pieces of f2c installation, leaving it to the sysadmin to do that,
  > as would be described in the g77 docs.
I'd tend to agree.  If we want to make their life easier we might
consider a configure time option to install f2c.h & libf2c.a
in /usr/local/..., regardless of the $prefix option.

I also get the feeling that f2c is becoming less and less important
as g77 continues to move forward and gain wider acceptance.  I can't
think of a reason to use f2c over g77 on the two platforms where I
do most of my work (hppa & x86).


  > So, I'd like to implement this removal, along with the relevant docs,
  > myself in the following release schedule:
  > 
  >   -  For g77, in version 0.5.23, the upcoming version that will also
  >      be the first to be based on gcc 2.8 (instead of gcc 2.7).
  > 
  >   -  For egcs, in version 1.1.
  > 
  > Please let me know if you see any problems with this idea, though
  > I'm also interested in "sounds like a good idea" messages as well.
They both sound good to me.


jeff

Re: Idea: Eliminate libf2c/f2c.h installation from g77 entirely?

[Mumit Khan]

Craig Burley <burley@gnu.org> writes:
> I'm thinking it might be time to eliminate from g77 any and all
> attempts to "help" the sysadmin by installing the libf2c.a and
> f2c.h files somewhere, which is currently done so that f2c users
> "automatically" use the same files as used by g77, making successful
> linking of executables combining objects generated by both g77 and
> f2c more likely.

I would like to see this "help" feature eliminiated as well. Then again,
I can't speak for f2c users.

This "help" has caused some headache here, and I've resorted to patching 
the Makefile to *not* install the extra copies of f2c.h and libf2c.a for
a few years now.

Regards,
Mumit

Idea: Eliminate libf2c/f2c.h installation from g77 entirely?

[Craig Burley]

I'm thinking it might be time to eliminate from g77 any and all
attempts to "help" the sysadmin by installing the libf2c.a and
f2c.h files somewhere, which is currently done so that f2c users
"automatically" use the same files as used by g77, making successful
linking of executables combining objects generated by both g77 and
f2c more likely.

(A short summary of the overall issues: g77 currently uses libf2c,
f2c's run-time library, for it's own run-time needs.  It ships with
a patched version of libf2c, but we've avoided creating gratuitous
incompatibilities in the interface.  That, combined with appropriate
effort in g77, allows users to pretty much pick and choose which
Fortran modules they compile with g77 and which with f2c, link
the objects together, and have things actually work, even including
starting I/O in a g77-compiled module and continuing it in an
f2c-compiled one.)

In the past it seemed convenient to try and offer this sort of
"one-stop shopping" from g77, but now I wonder whether this produces
more problems than it's worth.  A quick list of my thoughts on this:

  -  If f2c isn't being used, the only need for f2c.h (which g77
     generates its copy of via its configuration process from f2c.h.in,
     which in turn is just a modified copy of netlib's f2c's f2c.h)
     is when building g77's copy of libf2c.  There is no need to install
     this f2c.h anywhere; it's almost like an object file in this
     respect, in that, once the build is completed, it isn't needed.

  -  If f2c isn't being used, as long as g77 prefers "its" copy of libf2c.a
     (e.g. the one in $prefix/lib/gcc-lib/$machine/$version) over the one
     in the system's (/usr/lib) library, libf2c.a need not be installed
     anywhere else.  That is, it's really no different than the cc1,
     cc1plus, f771, and specs files, AFAIK.

  -  We've gotten bug report(s) that official-g77's method to determine
     whether the sysadmin wants libf2c.a and f2c.h installed is somewhat
     buggy.  (This method involves creating a file named `f2c-install-ok'
     in the source or build directory, or overriding a `make' macro
     when building.)  In fact, I just noticed that the f77.uninstall target
     in g77 0.5.22 uses the wrong pathname to delete f2c.h, a different
     bug than the one(s) reported.

  -  egcs apparently forcibly installs f2c.h in the system's include
     directory upon "make install" instead of "consulting" the
     `f2c-install-ok' mechanism described above.  At least one bug
     report has been filed about, IIRC, this problem, which is easily
     fixed regardless.

  -  The various configuration/build/install mechanisms employed by
     g77 -- meaning the ones in gcc 2.7, gcc 2.8, egcs 1.0, and, soon,
     egcs 1.1, all seem to agree, at least in principle, on the idea
     of explicit configuration of locations for where to install things.

     But this approach doesn't offer an elegant way to cope with what
     g77 is trying to do -- namely, install what amounts to part of
     some *other* product in a location the installer cannot control
     (except, modulo the egcs install bug, by enabling or disabling it).
     Especially since that other product is not (currently, I believe)
     distributed in a GNUish form, i.e. no GNU configuration, etc.

  -  From the above item, it seems practical to expect the sysadmin
     to be able, if not actually prefer, to make the decision when
     and where to move g77's libf2c.a and f2c.h to provide inter-
     operability with f2c.

A sysadmin who doesn't have f2c users won't care about what we decide
to do here.  A sysadmin who has f2c users who don't care about g77
inter-operability usually won't either, although perhaps there's some
bonus to getting g77's versions of libf2c.a and f2c.h (perhaps the
automatic configuration is nice).

Only a sysadmin who cares about g77 and f2c inter-operability will be
interested in what we do, and I believe that it'll be safer and more
robust, overall, to have g77 just "do its job" and not futz with bits
and pieces of f2c installation, leaving it to the sysadmin to do that,
as would be described in the g77 docs.

The only thing, other than a minor convenience, I can think of that
might be a problem is that sysadmins who don't notice that we've
removed this capability might end up thinking they've got a coherent
f2c+g77 installation when they haven't -- and that *might* result
in subtle problems down the road for users who combine f2c and
g77 objects in executables (e.g. if the API, or its implementation
in the egcs/gcc back end, changes subtly on the system).

I think that's not worth worrying about much, especially for egcs
at the moment.  For gcc, g77 could notice if the `f2c-install-ok'
mechanism is still being enabled and, if so, issue some kind of
warning, pointing to a relevant node in the g77 docs.  In any case,
it's not clear whether g77's even putting things in the right
place for the typical f2c/gcc interoperability-using installation.

So, I'd like to implement this removal, along with the relevant docs,
myself in the following release schedule:

  -  For g77, in version 0.5.23, the upcoming version that will also
     be the first to be based on gcc 2.8 (instead of gcc 2.7).

  -  For egcs, in version 1.1.

Please let me know if you see any problems with this idea, though
I'm also interested in "sounds like a good idea" messages as well.

In the long run, g77 should be improved to use a run-time library
better suited to its needs, which we've been calling `libg77',
though no real work has started on this.  One of the advantages to
a new library is that semi-mangled names for external (visible)
procedures can be used to significantly reduce the possibility
of inadvertent clashes causing subtle numerical bugs (as happens
for, e.g., cabs() between libf2c.a and, IIRC, a SunOS library).

Note that <199801161552.KAA18293@melange.gnu.org>, which should
be in the egcs mailing-list archives, is a message I sent that
attempted to describe the state of g77 vis-a-vis f2c.h, in
particular.  People wanting more info on the subject matter should
read that first.  I'm essentially proposing to undertake Choice 2
from a list of possible choices described in that email, now.

(I'm going to stuff this message in the g77.plan file too.)

        tq vm, (burley)