🚀 go-pugleaf

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

Hi All,

Background: running on a RedHat Linux 5.0 system (plus all errata).
Vanilla system, i.e. no more recent version of glibc or kernel; using
whatever is the latest redhat version on errata page.

I'm compiling a large code using Absoft Pro Fortran (f77 version 4.4).
I need to link to CERNLIB (a large package of scientific subroutines).
This package is available in many versions corresponding to different
compilers used to make the libraries.

Firstly, I was using the same Fortran compiler (Absoft v4.4) and
a version of CERNLIB compiled using g77, while running RedHat 4.2.
I had no problems at all with the code back then.

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

For those in the know, the routine where it All Goes South is
what_loop, which is a part of the KUIP command-interpreter package of
CERNLIB.  The details are expressed in an appendix below, thanks to
Absoft tech support.

Not knowing how to proceed, and suspecting that it was related to
libc5 vs glibc issues, I asked the C compiler and the linker to use
libc5 libs instead of glibc (using the -b option of ld, and other
options for gcc.  There is a Glibc2-HOWTO which tells you how to do
this.)

Problem: can't do it, since redhat only installs the old libraries but
not the old tools.  I get a "cpp not found" error since it looks for
cpp in some "libc5" part of the tree and not in the standard place.

Not being able to do this, I picked up Steve Adler's version of
CERNLIB 98a compiled using egcs/g77 under RedHat 5.0.  Surely this
should work.

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.

Problem: another difference of stock libf2c vs egcs libf2c is that the
egcs version defines the routine "main" within the library.  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?)

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!

					JAT

appendix: details of segmentation violation when using 97a CERNLIB
package.

abs> Jeff,
abs> 
abs> First, I've got say that running X over the internet is one of
abs> the more painfull things I've done lately. When the program is
abs> ready to return from what_loop (what_loop+0x1c7), the stack
abs> pointer is off by 4 bytes.  At the entry to what_loop, the
abs> stack pointer is 0xbffff3f8. On the last instruction of
abs> what_loop (what_loop+0x01c7), the stack pointer is 0xbffff3f4.
abs> This memory location just happens to contain a zero, so
abs> executing the return instuction sets the pc to zero. 
abs> 
abs> Some annotated assembly to ponder:
abs> 
abs>     what_loo+0x0193   call        exec_cmd_string  *1
abs>     what_loo+0x0198   pushl       %ebx
abs>     what_loo+0x0199   call        _init+0x0f0c     *2
abs>  => what_loo+0x019e   addl        $24,%esp	   *3
abs>     what_loo+0x01a1   movl        $0,kc_break+0x000c
abs>     what_loo+0x01ab   cmpl        $0,kc_flags
abs>     what_loo+0x01b2   jnz         what_loop+0x01c1
abs>     what_loo+0x01b4   cmpl        $0,kc_flags+0x0004
abs>     what_loo+0x01bb   jz          what_loop+0x0040
abs>     what_loo+0x01c1   movl        $1,%eax
abs>     what_loo+0x01c6   popl        %ebx		   *4
abs>     what_loo+0x01c7   ret
abs> 
abs>     *1 - we got back from exec_cmd_string, so the stack was ok
abs>     to this point.
abs> 
abs>     *2 - this is a call into a shared library, the routine is
abs>     cfree and apparently gets one argument. Also, this function
abs>     returns ok, so the stack is still good.
abs> 
abs>     *3 - after this add of 24 bytes, the stack pointer is
abs>     0xbffff3f0.
abs> 
abs>     *4 - this adds another 4 bytes to the stack pointer, giving
abs>     0xbffff3f4.  But at entry to what_loop, the stack pointer
abs>     was 0xbffff3f8 so we can't to a ret instruction until
abs>     another 4 bytes are added to the stack pointer. Bug. 
abs> 
abs> 
abs> So who compiled the what_loop function - Absoft or gcc?