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

[Craig Burley <burley at gnu dot org>]

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