Idea: Eliminate libf2c/f2c.h installation from g77 entirely?
Sat Apr 18 16:05:00 GMT 1998
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
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
- 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)
More information about the Gcc