forums.silverfrost.com

[wosl]

Since a while I try to get around of a phenomenon which sounds to me a typical compiler/linker error.

My ClearWin Fortran Program has currently approx. 11.000 statements with 270 subroutines/functions sliced in multiple Fortran files. In addition I need to link some C code for Windows API calls. I'm using the FTN95 version 5.20. Programs are compiled and linked for debugging with /undef and /full_debug options.

Two typical events are happening sometimes:

1. Linker error occurs saying that he could not find a specific subroutine or function, but which is definitely available in the source code.

2. More strange and very heavy to detect is a behavior during run time. It happens that a variable is getting overwritten in memory unexpectedly. I dedected it using the write_break feature in sdbg. This always happens while calling a routine (which has nothing at all to do with the mentioned variable) from the stack.

Remembering this behavior from the past (with other compilers ...) I enhance the internal heap stack in WINAPP. But the problem still occurs. I guess it's an issue with the linker. Is there any linker parameter that could help to avoid that mistake?

I found out the following work-a-round:

If I flip the involved subroutines in a different sequence in my code file or cut them out into a separate .for file it seems to work. In other words, I didn't change any source code statement, just influencing the linker to link the routines in a different sequence.

To be honest, this drives me very nervous because I don't know the reason and, especially the behavior item #2 is very hard to detect. It took me days to make sure that it's basically not my programming fault.

Has anybody similar experiences? Any suggestion is welcome.

WoSl

[JohnCampbell]

some ideas on your problems:

"Linker error occurs saying that he could not find a specific subroutine or function, but which is definitely available in the source code. "
Check the spelling of the subroutine, or did it compile? it may not be in the .obj file, or the .obj file may be missing.

The second looks very much like a programing problem. It's either addressing an array out of bounds or inconsistent argument lists for subroutine calls. One way to get the compiler to help is to compile with /check and also list all .f95 files in a single file as includes and then compile this single file. eg the file "all_code.f95" consists of

include 'file_01.f95'
include 'file_02.f95'
...
include 'last multiple file.f95'

I assumed you used .f95 free format file name extension. If you are using fixed format .for files, then the coding errors are easier.
I don't know how to mix fixed and free format code in the one file but it may be possible. Or use 2 files.
The purpose of grouping all files in the single compile is that ftn95 does do some argument list checking, and you never know what may be found.
Inconsistent argument lists is a big area, especially when mixing f95 and C.
This is certainly not a big program for the linker.

good luck

[LitusSaxonicum]

John,

Some useful ideas here for all of us.

Can't you embed OPTIONS (FREE) and OPTIONS (FIXED) in between the INCLUDEs ?

Eddie