Initialisation problem related to a special module situation

When porting a 32 bit application to 64 bit using Salford ftn95 8.40, we ran into a problem in context with a special module situation.

We have a fortran file consisting only of a module definition defining and initialising 2 variables. The module is used in a second (main) source which displays both variables of the module. It depends on the way we build the stuff if the output values are corect or not. Especially we cannot build a library consisting only of the object file built from the module file.

Module source file (mod_def.for):

      MODULE MYMOD
      REAL*8 :: VAR1 = 10D0
      REAL*8 :: VAR2 = 20D0
      END MODULE

Main source (mymodules1.for):

      use mymod
      
      write(*,*) 'VAR1=',VAR1
      write(*,*) 'VAR2=',VAR2
      
      end

Using link file mod_def.lnk

lo mod_def.obj
;lo mymodules2.obj
file mod_def.lib

causes an access violation when trying to create library mod_def.lib. Adding/decommenting loading file mymodules2.obj in the link file makes the library be generated as expected. Here mymodules2.for contains a function not used in the main program.

The main executable is created using link file

lo mymodules1
;lo mod_def.obj
lo mod_def.lib
file mymodules1.exe

Now executing mymodules1.exe results in the values 0.00000000000 for both VAR1 and VAR2. If I load object file mod_def.obj instead of mod_def.lib when linking mymodules1.exe and execute mymodules1.exe, then the proper output

 VAR1=          10.0000000000
 VAR2=          20.0000000000

is displayed.

This is not a serious problem for we can use the module object file in the context of our port mentioned above. However, originally we intended to use an analogon to the module file situation above where the module object file was contained in a library and this caused the wrong initialisation.

Regard, Dietmar

I have made a note that this needs investigation.

Dietmar

The access violation has now been fixed but not in time for the next full release of FTN95. I can let you have a patched SLINK64 that includes this fix after the next full release.

This is not all good news. The outcome for the setup that you describe will not be what you currently experience for 32 bits. To be precise, the variables will be initialise to zero unless the module also contains a subprogram that is required when linking.

The natural behaviour of the linker is to scan any offered libraries in order to located missing subprograms. This is clear and simple. But there is no obvious strategy for handling module variables that could potentially be scattered as a result of module subprograms appearing in separate object blocks.

For the moment we have decided to reserve our position regarding the linking of module variables via a static library. This will mean that SLINK64 will initially behave differently from SLINK in this context and that the behaviour of SLINK64 may change in future in this regard.

If this approach is important to you then I suggest that you keep the relevant variables in a dedicated .obj file (var.obj say) rather than archiving them into a static library. This will require you to link with var.obj for the variables whilst (optionally) using a separate static library for any subprograms (including module subprograms).

Another approach (which to me is simpler and more robust) is to avoid this kind of module data initialisation and to write and call a module subroutine that does the initialising at run time.

Dietmar,

You are obviously far more sophisticated in your programming style than I am (from the discussion in your post), but can I reiterate Paul's observation that you are better off doing all the variable initialisation in a named subprogram called early in program execution? There is a benefit from doing the initialisation explicitly with assignment statements, and that is because you can call the subprogram to re-initialise the values. This corresponds to 'New' in the 'File' menu. Named subprograms will always be reported as missing if they aren't found when the linker does a 'roll call'.

If you initialise with DATA statements and/or the newer facilities in later versions of Fortran, you can only reinitialise with assignment statements anyway. There is also the problem of things missed out from the link stage. This is analogous to missing out a BLOCK DATA routine in old-style Fortran. I'm lucky that I never got into BLOCK DATA because several compilers I used didn't have it, but there were tricks (such as using named BLOCK DATA and mentioning the name in an EXTERNAL statement) that worked much of the time.

Eddie

Eddie, Paul,

thanks for your infos.

I am fine with putting the relevant variables in a dedicated .obj file. I think I mentioned that in my post.

And I'm fine with Paul's suggestions.

I also agree with Eddie that it might be a good strategy putting initialisation stuff into a subprogram.

However, I was porting a 32 bit program to 64 bit and for 32 bit everything worked fine. So I did not want to change the source code if not neccessary. And as the module object file was put into a static library for the 32 bit build I tried to do the same in the 64 bit build.

As this did not work I tried to find out why not and made the observations mentioned above.

Regards, Dietmar