g77 (was *.f *.c linking problem)

[Craig Burley]

>So you are saying that gcc 2.8.1 <> egcs 1.0.3a, and g77 0.5.23 is a later
>package; and the next update in the gcc/g77 scenerio is egcs 1.1 which
>will come out in about a month's time? 

Yes, though whether 0.5.24 comes out before or after that, I can't
guess right now.  It's likely to be almost identical to the egcs 1.1
version of g77.

>I think the development effort should be more co-ordinated - besides it
>being duplicating efforts, it is a terrible mess to have to cope with
>three version of libf2c (GNU's egcs', and netlib's) and two versions of
>gcc and g77; okay, netlib's is less of a problem because I put them into a
>different directory, and only do an explicit -L there (if I have to); but
>the gcc/g77 stuff goes with the system and they actually over-write each
>other (at least the binary). 

I agree, it'd be great.  But what do you suggest -- should I stop
working on egcs-g77, or on gcc-based g77?  Do you think everyone
will agree?  And if I stop, that won't make the multiple versions
go away, will it?  Just make them less compatible over time, right?

What I do is use --prefix when I configure, and give every version
of g77 its own directory.  Then I specify which one I want to invoke,
and/or link /usr/bin/g77, /usr/bin/gcc, and so on to that version.

>Can we make them function more similarly to the proprietary Sun compilers
>(or others)? I think the Sun f77 compiler wouldn't moan if you compile c
>codes with it... Not sure whether this is a "correct" practice, but there
>are strange people out there who write fortran codes then a C wrapper,
>etc. Porting these codes are difficult.

g77 doesn't complain about compiling C code either, except for the
version in egcs 1.0, which, like g++ and such, happens to be broken
in this regard.  egcs 1.1 fixes that, but AFAIK only for g77, not
for g++.

>I will wait for the next egcs...

Okay.

        tq vm, (burley)