generation of names for linker

[Jay_B_]

Howdy.  More on my super-legacy application (which actually consists of a few large programs and a couple of dozen smaller ones).  If am over-using my access to this forum, just say so.  Then again, this could be a pretty interesting topic in terms of Fortran history -- did I mention that source code is actually in a custom dialect of RATFOR?  All of the FORTRAN I've discussed is machine-generated.  (That will either interest you more, in terms f software archaeology,  or drive you away!)

One of the low-level function "RATFOR library" functions invokes a routine called FGETC, which is supposed to grab the next character from a numbered input unit.  It is called as a routine (no return value), and passed 3 arguments.  There is no source code for this routine, which tells me that it's expected to be in the g77 library.  But this name conflicts with a function named fgetc() in the GNU C library, with a type if integer and one argument, a pointer to a stream.

But that's not the only mystery.  When I segfault in the call, the backtrace shows:

(gdb) bt

#0  0x000000360ca67efa in getc () from /lib64/libc.so.6

#1  0x0000000000479fc6 in rgetch (c=.FALSE., chan=13) at rgetch.for:12

#2  0x0000000000478653 in getch (c=.FALSE., f=1) at getch.for:17

#3  0x0000000000472fe6 in fbin (jfn=1, char=.FALSE., ierror=542725204)

    at lbfjfn.for:102

#4  0x00000000004702b3 in getfch (char=.FALSE., idly=1, iarg=0)

    at lbecho.for:470

How did fgetc ()in the code become getc() in the link?

Thanks,

Jay

[TimP]

It looks like fgetc (from libg77 or libf2c, source code should be readily available, e.g. on netlib f2c or g77 mirrors, although rather ancient) is written in terms of getc().  If you want to go that route, simply add that C source code to your project.

My preference with ratfor has been to modify the translator so as to produce reasonably legible f77 with a bit of f90, so that the code can be transitioned to Fortran.

[Jay_B_]

That is exactly my goal -- to transition to f90 or later gradually.  One reason is -- hold onto your hat -- the original RATFOR source has been lost (somehow, a machine-generated FORTRAN 66/77 version of it survives).  We would replace RATFOR code with f90 gradually -- which is exactly why Intel Fortran is the best choice of compiler.

Other RATFOR processors were tested, and could not handle the extensive use of nested/recursive macros upon which this application depends.

Jay 

[Izaak_Beekman]

Jay B. wrote:

One reason is -- hold onto your hat -- the original RATFOR source has been lost (somehow, a machine-generated FORTRAN 66/77 version of it survives).  

I hope that you, sir, are well remunerated for your toils. That sounds most unpleasant.

[Jay_B_]

:--)

We have a chance to resurrect a simulation model that was heavily used during the last 2 decades of the 20th century.  Users who abandoned it at the turn of the century might come back if there is a forward-looking development path.

[Steven_L_Intel1]

Do you know for sure that getc is being called, or are you just determining that from the traceback? Have you done an nm -a on your .o or looked at the .s file? I think you're chasing the wrong thing.

Intel Fortran does support FGETC in its portability library. Add USE IFPORT to get access to it.

[Jay_B_]

I actually stumbled upon that solution after some more research on Google about fgetc.  Sorry I didn't close the loop. 

Thanks much,
Jay