🚀 go-pugleaf

Jeff Templon <templon@studbolt.physast.uga.edu> writes:

> [ comp.lang.fortran people: sorry for all the specifics, but there is
>   a genuine Fortran (egcs/g77) question near the bottom. ]

I'll try to give some info from my perspective, though I can't
really answer any of your problems directly, I'm afraid.

> Now under RedHat 5.0, the exact same code, linked to the exact same
> libraries, dies with a segmentation violation.  At some point in the
> bowels of CERNLIB, the stack gets corrupted and a "return" statement
> causes the program to land at an address 0000000.  What's weird is
> that this should not happen, since this portion of the code has not
> changed at all in the upgrade from redhat 4.2 to 5.0 (barring some
> strange disk error!)

Tim Prince, IIRC, complained about some strange I/O bug(s) he
was running into with g77 built on his RH 5.0 machine.  I can't
recall being able to reproduce them on my RH 5.0 machine, though
I think I've installed most or all of the `update' packages
from RH already, which might account for the differences; not
sure I was ever able to get ahold of a complete test case to
try to reproduce it, however.

But, I think he discovered that upgrading his libc5 or something
fixed the problem.  Which is confusing, because apparently glibc2
is used by default.  I hope he sees your post and responds with
some info that's more useful than what I'm speculating about.

> Problem: egcs/g77 "libf2c" package is not really the same as the real
> libf2c as distributed by AT&T.  Thus the link phase complains about
> missing symbols.  So I pick up egcs-1.02 and install it so that I have
> the version of libf2c which this CERNLIB expects.  Compile and link.

netlib's libf2c hasn't been integrated into egcs' copy for some time.
However, there shouldn't be missing symbols, except for libU77
stuff like dtime_ and etime_, which would normally get called
by g77 as G77_dtime_0 and G77_etime_0.  It's a long story, but
if you tried, you could probably add egcs/g77's libU77 to your
netlib-libf2c tree, though it takes me a long time to do stuff
like this for g77.

> Problem: another difference of stock libf2c vs egcs libf2c is that the
> egcs version defines the routine "main" within the library.

So does stock libf2c, at least, last time I checked.

> Thus,
> when I try to link it only as a support library, and the main routine
> is compiled with _another_ compiler (Absoft), I get *two* main
> routines defined.  I don't know the implications of removing the
> "main" routine from libf2c (does g77 I/O work if I do this) nor do I
> know how to convince the loader how to do this (do I simply remove
> main.o from libf2c using the 'ar' command?)

I think g77/f2c I/O works without going through libf2c's main, but
exception handlers aren't necessarily set up as you might expect.
See libF77/main.c for what goes on.

Why there's a problem having main.o in libf2c is beyond me.  Seems
to me that as long as you link only *one* "main program unit"
(Fortran "PROGRAM"), crt0.o or crt1.o or whatever calls main_
should be linked to that, instead of the linker pulling in
libf2c/main.o.  It shouldn't matter, in this sense, whether the
main program unit is compiled by g77/f2c or Absoft, assuming
Absoft compiles main_ or MAIN__, because crt[01].o calls main_,
which is either produced by Absoft or is linked to libf2c's main_,
and the latter calls MAIN__.

Of course, if you put the .o's compiled by Absoft or g77/f2c,
and these include a main program unit, that can make for problems,
since you have to worry (more) about command-line ordering when
linking.

Isn't this fun?

> In short: I am stuck -- the only recourse I know is to downgrade to
> RedHat 4.2.  Anyone who has any suggestions, ideas, or solutions
> is extremely welcome to pass them on!

Another possibility is to wait for g77 0.5.23 to appear, grab
that, and recompile everything in sight.  That might improve
things, make things worse, etc., but it'll be a "cleaner" release
based on gcc 2.8.1.  Watch <ftp://alpha.gnu.org/g77.plan>.
-- 

"Practice random senselessness and act kind of beautiful."
James Craig Burley, Software Craftsperson    burley@gnu.org