Re: Patch: f2c.h Question: objc backend

[Craig Burley <burley@gnu.org>]

Here's what I think is the "complete story" on g77's treatment of
`f2c.h'.

g77 relies on the f2c run-time library, named libf2c.  That means
it generates object-compatible calls to that library.

So, with little additional pain, g77 is able to offer object
compatibility with f2c.  [FYI: f2c converts Fortran code to
C code, which the user in turn compiles with a C compiler such
as gcc.]

That is, users can mix g77-compiled and f2c-compiled code in a
single program.  Not only can each kind of object call on the
same library in a "mixy" way -- e.g. g77 code can OPEN a file
on unit 10, then f2c code can WRITE to unit 10, and it all works --
but each kind of object can call on the other (which makes the
former practical).

For reasons involving portability and simplicity, plus being
still fairly primitive, `libf2c.a' is built using some fairly
"brittle" assumptions about data types that affect how
callers pass arguments to `libf2c.a' routines.

These assumptions are encoded in a file named `f2c.h'.

This file is #include'd by `libf2c.a' code, and also is #include'd
by f2c-produced code when it is compiled by the user's C compiler
(which should be the same, or object-compatible with, the one
he used to build `libf2c.a' itself).

Absent g77, f2c installers are encouraged to tailor `f2c.h' to their
system by editing it prior to building `libf2c.a', then making
that edited copy available as the version for all f2c users
who will link to that particular library.

So, a typical f2c installation has a version of `f2c.h' installed
wherever local `.h' files live such that they'll be (automatically?)
picked up when compiling C code produced by f2c.  This version might
or might not have been hand-edited by the f2c installer (probably
not if the system is SunOS, IIRC).

This means that, for most systems, /usr/local/include/ is the
place where `f2c.h' is installed.

Now, g77 enters the picture, and certain things happen.

g77 generates its own version of `f2c.h' during its configuration
(and build?) procedure from a file named `f2c.h.in'.  This allows
g77 to configure and build more automatically than the f2c version
of libf2c would by itself (though, perhaps official f2c+libf2c
has improved since this was last known to be a problem a couple of
years ago).

The g77-generated version of `f2c.h' is, in effect, *already* a
"hand-edited" version in the narrow libf2c sense.

So, to make this version of `f2c.h' available to users of f2c
on the system, g77 installs it, along with the version of `libf2c.a'
it built, in the canonical include and lib directories if `libf2c.a'
isn't already there or explicit overriding macros and/or files
exist in the build or source directories.

Little of the above *isn't* some kind of kludge, so there's
little of it that can't be reworked, as long as the rework
is done with some overall understanding of the situation, what
is being achieved, and so on.

For example, installing `f2c.h' in some other directory instead
might or might not be a good idea.  It depends on whether f2c
users are likely to pick up that version when linking to the
corresponding `libf2c.a'.

The problem is essentially that g77 is trying, bless its heart,
to get along with the gcc configuration and build environment,
and for most users it succeeds very well.

But it also tries to "eject matter" that will coexist with an
independently provided and separately built and installed product,
f2c, which has pretty much no similarity to gcc's build
environment.

There's a variety of "futures" issues that perhaps suggest various
ways to resolve this situation:

  1.  We could bring all of f2c into the gcc/g77 product packaging.
      It wouldn't take much additional space, but could take a fair
      amount of work to get all the configuration, build, and porting
      issues resolved enough to make it worthwhile.

  2.  We could start to drop any semblance of f2c compatibility from
      g77, leaving it to "knowledgable" users to do the f2c-related
      installation by hand.  The continued use of `libf2c.a' would thus
      be essentially "hidden" from the user base by not installing
      `libf2c.a' anywhere other than in the version-specific library
      directory.

  3.  We could start writing libg77.a, the name we've unofficially
      given the long-term replacement for `libf2c.a' we've been wanting
      to do for years.  libg77.a would *not* offer any compatibility
      with `libf2c.a'.  Whether g77 offered a "compatibility flag" to
      produce code compatible with `libf2c.a' is undecided, but the
      "hook" is there for users who want such compatibility.  (I.e.
      they already have a compiler option they can use, which we can
      start handling by producing a diagnostic when and if necessary.)

Items 2 and 3 are fairly compatible, i.e. we could do 2 now and
3 later.

Doing item 1 might be more helpful to current g77 users, but I'm
not sure how much harder it might make a transition over to 3
(perhaps via 2) in the future.

In any case, we *know* we want to do 3, it's just a matter of timing,
and, probably, funding.  We need a multi-libbed g77 library, one
that handles exceptions, threads, more features, higher performance,
the whole kit and kaboodle.

        tq vm, (burley)