Bug with /UNDEF and global variables via COMMON in a DLL...

If you declare a variable in a common block, and you define it in a subroutine(SET_DEFAULT), then if the subroutine is in a separate file but linked into the main.exe as an obj, then it works fine, but if the separate file is compiled and linked into a DLL, which then is loaded during compilation, then it will fail under UNDEF (reference to undefined variable).

ftn95 /windows /zero /f2k /cfpp /free /64 /undef /debug LIBRARIES.for ftn95 /windows /zero /f2k /cfpp /free /64 /undef /debug main.f90 slink64 libraries.obj /file:libraries.dll slink64 main.obj libraries.dll /file:main.exe

It fails also under 32bit.

SUBROUTINE SET_DEFAULT()
INTEGER*4 IVERS
INTEGER(kind=7) IADD

COMMON /EZ/ IVERS, IADD

 INTEGER*4 :: IVERS2 = 10
 INTEGER(kind=7) :: IADD2 = 30429112

 IVERS = IVERS2
 IADD  = IADD2 
 
END SUBROUTINE


PROGRAM MAIN
INTEGER*4 IVERS
INTEGER(kind=7) IADD
COMMON /EZ/ IVERS, IADD
  

 CALL SET_DEFAULT()

 PRINT*,'IVERS=',IVERS
 PRINT*,'IADD=',IADD

END PROGRAM

That is what I would expect. Common blocks are linked via SLINK/SLINK64. They can't be linked dynamically at load time. In other words you can't share data between an executable and a DLL via a common block.

So I am guessing they would have to be in a module file if a DLL file is a used (and undef). But in that case isn't is surprising that it works without UNDEF and the values are correct?

Module data behaves in the same way as data in a COMMON block so it can't be linked at load time. Module functions are OK.

/UNDEF will reveal undefined data. If you don't use /UNDEF and you don't initialise the data then you will get garbage (hopefully zeros but maybe not). In your program the garbage must be having no visible effect.

You are absolutely right. Actually we never had this problem before because all the files using variables defined in COMMON blocks would be linked into a single DLL, but because with the 64bit version we got an error, we had to split into multiple DLLs. I mentioned this last time, I believe you increased the buffer size and indeed we can now include more files in a DLL but still not all the ones we need - perhaps you could increase the buffer size a bit more? Thanks

If it is the buffer that I am thinking of then it is currently set at 100 million bytes.

Would it be possible to increase the buffer size to, say, 200MB? This problem becomes more pronounced when we use debug files by the way, so we need to split into even more DLLs when using the debug option. Thanks

I will add this to the list.

Here is a new SLINK64 for you to try...

https://www.dropbox.com/s/mhyia7e6tsa1qe9/Slink64_2.zip?dl=0

Thanks, I just downloaded it and replaced the older SLINK64. Unfortunately I am still getting the same error (not sure if the output below is helpful).

Runtime error from program:c:\program files (x86)\silverfrost\ftn95\slink64.exe Access Violation The instruction at address 0040482c attempted to write to location 13007000

00404568 load(<ptr>char) [+02c4] 00401000 main [+0a2b]

eax=06276000 ebx=06275eaa ecx=034feeaa edx=03a306c0 esi=1da8e198 edi=13007000 ebp=0367ec8c esp=0367eba8 IOPL=1 ds=002b es=002b fs=0053 gs=002b cs=0023 ss=002b flgs=00010246 [NC EP ZR SN DN NV]

0040482c rep 0040482d movsb 0040482e mov ebx,[edx+0x4]

Here is another update for you to try...

https://www.dropbox.com/s/qs1eh3fyfq7qnjb/Slink64_3.zip?dl=0

That seems to have fixed it! I have now included two large files in debug mode and I was able to link successfully. I will let you know if this problem pops up again. Great work!

We are still having an issue with a large Fortran file (in 64bit only)- I need to split the actual Fortran file into smaller sized files, and then the linking works. We have just one DLL at the end (and not multiple like before), which is great, but for the linking to work, I need to split the Fortran file into smaller parts (via a script), recompile and link the smaller object files. Do you think this is still a buffer size issue? Thanks

If there is an internal buffer overflow when using SLINK64 then you should now get a clear error report to this effect.

How does the error present itself?

The only error I am getting is '***Corrupt symbol reference' and slink64 stops. Since by splitting into smaller files fixes the issue, I think it points to a buffer overflow rather than a symbol reference issue.

If you can send everything to me then I should be able to track it down.

I sent it to you, thanks

This has now been fixed and a new SLINK64 is available here...

https://www.dropbox.com/s/6hdtlog0x1o1dli/Slink64_4.zip?dl=0

I can confirm this is fixed. Great job!