DLL Compatibility

[Intel_C_Intel]

We provide a FORTRAN DLL workspace to our internal users that allows them to update our core product / add new routines. The DLL links against the main EXE lib file and imports some common blocks from the executable.

For our latest release, somehow, the lib file we have under source control does not seem to be compatible with the executable. At least, if I use it to create a DLL, the DLL compiles and links OK, is loaded by the EXE OK, but under debug shows that the common block have not been imported correctly.

Does anybody have any ideas about how to track this? Ideally, I'd like to be able to create a DLL workspace including a lib file compatible with the EXE we've already released. I guess I'd need a tool that could tell me if a lib file is compatible with its EXE equivalent - anyone know of such a thing?

I have done a full recompile on the released sources and that produces internally consistent results- an EXE and lib file that can by used with the DLL workspace, but that lib file does not seem to be compatible with the released EXE either. Two sample lines from the lib file under diff show:

Rebuilt from released sources

_PRIVATE RtoOle.exe RtoOle.exe/ 1073667495

Release lib file

_PRIVATE RtoOle.exe RtoOle.exe/ 1063817383

where PRIVATE is a common block name. I don't know anything about the format of lib files so I don't know what this means.

Help greatly appreciated on this one,

Dan

[Intel_C_Intel]

OK, I figured out what the problem was here. The exe was built with 6.6B, the DLL was built with 6.6C. So I decided to do a little checking. A DLL built with 6.5, 6.6, 6.6A and 6.6B works against the 6.6B EXE, but a 6.6C DLL doesn't work.

What went into 6.6C that 'broke' it, and how much backward compatibility should we expect?

(It really just means that we'll have to advise our project guys not to be too hasty in upgrading their compilers!)

Dan

[Steven_L_Intel1]

We're aware of one incompatibility which was not deliberate - if you have a derived type or structure that contains one or more POINTER or ALLOCATABLE components, 6.6C adds 4 bytes to the end of these components, shifting any that follow.

Steve

[Intel_C_Intel]

Steve,

Sounds like the very thing - the common block in question contains a number of allocatable arrays.

I guess since no more updates are forthcoming this isn't going to be 'fixed' (not that it should matter once we get everyone onto the same compiler version).

Dan

[Jugoslav_Dujic]

Steve,

I assume the extra DWORD padding occurs only with array pointers, as I didn't notice the difference with scalar pointers (I have a multi-language project where char* structure componentsare mapped to character, pointer(*). Sizeof's are (luckily) checked on both sides and I didn't notice the difference -- albeit I'm still on the "old" 6.6C upgrade, if it matters).

I suspect it would also break multi-language projects where VF array descriptor is translated to host language for the purpose of data exchange.

Jugoslav

[Steven_L_Intel1]

Yes, this is array pointers only.