Shared Memory DLL Conversion from Compaq Visual Fortran

[dbnichols]

Hello,

I have been converting various projects from CVF to IVF over the past several weeks, in an attempt to make sure our company can move forward with Intel w/o any major hiccups.

We've had a fair share of problems but have been able to overcome them all, except for this one last hurdle.
We have a CVF DLL, which is a shared memory DLL that almost every other program will be accessing in our system. This worked fine with no problems in CVF, and the DLL complied in CVF 6, is approximately 180MB in size.

I've run the project through the conversion process, and tried to get it to recompile, which it does, however it has a LINKER warning. It is as follows:

LINK : warning LNK4092: shared writable section '.data' contains relocations; image may not run correctly

This generates a DLL, but it is approximately 120MB in size, which is roughly 1/3 smaller than the original VCF compiled DLL.

Furthermore, it does not work, and the system will not access the DLL. Any ideas would be appreciated.

Listed below are the Fortran ALL Options:

/nologo /debug:full /Od /D_NEWUI /D_PID24 /D_QL30002 /D_LTA_PI /fixed /extend_source:132 /Qsave

/align:commons /iface:cref /assume:underscore /model:"Debug/" /object:"Debug/" /libs:static /threads /dbglibs /c

Listed below are the Linker All Options:

/OUT:"Debug\\glpms.dll" /INCREMENTAL:NO /NOLOGO /MANIFEST /MANIFESTFILE:"N:\\ENGLIB\\GLBPMS\\Debug\\glbpms.dll.intermediate.manifest" /DEBUG /PDB:"Debug/glbpms.pdb" /SUBSYSTEM:WINDOWS /IMPLIB:"N:\\ENGLIB\\GLBPMS\\Debug\\glbpms.lib"

/MACHINE:IX86 /DLL kernel32.lib

Listed below are the Linker Additional Options:

-section:.data,rws

Any ideas would be most appreciated.

Regards,

Bryan

[Xiaoping_D_Intel]

Change "/libs:static" to "/libs:dll" should be able to resolve the problem. Why use "/libs:static" when generating a dll?

[Steven_L_Intel1]

There is a sample provided "DLL_Shared_Data" which does what you are looking for. I will comment that the variable or COMMON you are sharing needs to be data-initialized to a non-zero value in order for the sharing to work.

[dbnichols]

Steve,

Are you saying that ALL of the variables in the shared DLL have to be data initialized within the DLL? I've played with the sample, and have it working fine. I've also compiled my OLD, OLD inherited project which is mostly Fortran 77, and I can read values like the parameters fine.

However, mostly none of the hundreds and hundreds of shared variables are data initialized. Here is some sample code from the DLL:

[bash]      CHARACTER*(M_PID)
     * ZEX_BACNAME(MAX_TRANQUE),
     * ZEX_RTSNAME(MAX_TRANQUE)

      PARAMETER MAX_TRANQUERDB=150

      INTEGER*4
     * IEX_RDBHEAD,
     * IEX_RDBNEXT(MAX_TRANQUERDB),
     * IEX_RDBSTATUS(MAX_TRANQUERDB),
     * IEX_RDBTAIL,
     * IEX_RDBTRAN(MAX_TRANQUERDB)
[/bash]

Of these, I can link to the shared DLL and see that MAX_TRANQUERDB returns a 150 as expected. All of the integers return a 0, but I can't change them. The strings, are empty, and I cannot change them either.

Since this is F77, and not F90, how would I go about pre-initializing the data to a non-zero value? And, moreover, what if, the CORRECT default is a zero value to start with?

Regards,

Bryan

PS: As far as the initialization goes, what about character strings & bytes & arrays? How do those need to be initialized?

[dbnichols]

Also,

I get the following when I try to access an integer or string (parameters seem to work fine) during the build:

[bash]DebugGLBPMS_Monitor.obj:warning : locally defined symbol __imp__EXECTAB imported
GLBPMS_Monitor.obj : warning LNK4217: locally defined symbol _EXECTAB imported in function _MAIN__[/bash]

Any ideas?

Thanks,

Bryan

PS: It builds with the warning for the integer. When I access it in a "monitor" program to read the value, it always returns zero, even if I defined it as say:

[bash]integer*4 test_integer_var /999/[/bash]

Which, I would expect to return back the value of 999.

Thanks,

Bryan

[Steven_L_Intel1]

It would help me to see a ZIP of a complete solution that shows the problem.

The linker warnings are harmless and can be ignored.

[dbnichols]

Ok,

I added a stripped down DLL and a console app that is linked to it to read out a couple of parameters, a real and an integer.

If I access only parameters, everything compiles and runs fine. If uncomment the lines to display the integer / real variables, I get a compile time error like this:

[bash]Compiling with Intel Visual Fortran 11.1.035 [IA-32]...
GLBPMS_Monitor.f90
Linking...
GLBPMS_Monitor.obj : error LNK2019: unresolved external symbol _GLBPMS_mp_NTC_TEST_INTEGER referenced in function _MAIN__
N:OBJECT90DebugGLBPMS_Monitor.exe : fatal error LNK1120: 1 unresolved externals[/bash]

I was trying to create a subset of this massive DLL for you to see the problem I'm having, but once I parred it down, I now have this new issue. Any ideas?

Thanks,

Bryan

[Steven_L_Intel1]

In the sources you sent me, there was no DLLEXPORT of the shared variables. The error you saw indicates that you did not link the "monitor" program against the export library of the DLL, but no export library would have been created since the DLLEXPORT was missing.

I added a DLLEXPORT directive in the module and initialized the value of the integer variable so I could see what it was, and it worked.

Will you have multiple programs sharing the same DLL and communicating values through the DLL? It was not clear from your cut-down sample if you were.

[dbnichols]

Steve,

1. Do I have to to something like this for every variable?

[bash]      !DEC$ ATTRIBUTES DLLEXPORT :: NTC_TEST_INTEGER1
      integer :: NTC_TEST_INTEGER1
      
      !DEC$ ATTRIBUTES DLLEXPORT :: NTC_TEST_INTEGER2
      integer*4 NTC_TEST_INTEGER2 /250/
[/bash]

2. Or, is there a module-wide DLLEXPORT directive so that all of the variables will be visible?

3. Yes, multiple programs access this DLL

4. The DLL actually consists of about 20 or 30 include files, each of which has a set of variables declared for a specific section of the system. For example, there is a GLOBALS.I file (for global variables) and an ALARMS.I file with alarm specific variables, etc. etc.

5. If the data must be initialized to NON-ZERO values, what about REALS, and character strings, and logicals, and bytes, etc.? What / how are those to be initialized?

Regards,

Bryan

[Steven_L_Intel1]

1. Yes.
2. No.
3. And they all want to share the same up-to-date value of the shared variables?
4.
5. Yes. However, if you add the option /Qnobss-init , you can initialize to zero, but you must initialize any variable you want to be read-write shared (placed in .data). This goes for reals and characters too - obviously, a character can be iniutialized to blanks, etc.