(970922) install-f2c-header problem and suggestion

[Craig Burley]

>So the question now becomes is being consistent internally (ie if
>you use --prefix, then egcs shouldn't be scribbling elsewhere in
>your filesystem) more important than making things work if someone
>has already installed f2c?

I think the current behavior (at least in official g77) is the
former.  That is, normally it wouldn't do anything about an installed
f2c.

However, I usually configure my g77 so it *does* install the f2c.h
and libf2c.a files.  I do this by "touch"-ing a file named
`f2c-install-ok' in the build directory before I configure and
build g77.  Defining a macro named F2C_INSTALL_OK achieves the
same effect.

In a similar vein, g77 checks whether /usr/lib/libf2c.a exists
when installing libf2c.a.  If it does, it prints a big warning
about the possible dangers of having different copies of libf2c.a
installed in different places.  (Similar problem if different f2c.h's
exist, etc.)

This is all stuff that will go away when/assuming g77 stops
supporting f2c compatibility.  We're already "feeling" the
performance and, to a lesser extent, features limitations by
sticking with f2c compatibility, so maybe that'll happen sometime
next year.

In the meantime, another approach to solving this kind of inelegance
is to add f2c to the g77 distribution, that is, have installing
g77 include installing f2c, and GNU-ize the f2c part (of course).
I don't think it's worth it, myself, because I get the impression
fewer people care about combining g77 and f2c now that g77 supports
some of the basic things f2c did like INTEGER*2, and g77 performs
pretty well.  But it's still worth considering.

        tq vm, (burley)