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

[Craig Burley <burley at gnu dot org>]

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