LNK2019 - x64 DLL naming convention trouble

[sebastien_jaffre]

I have some code that I'm porting to x64 and I get some unresolved external symbol troubles when I make the link.

The error concerns the symbols "__imp_aandia_mp_a" and "__imp_aandia_mp_ia" which are not matching the symbol the ones provided by a 64bits dll. If I compare the symbol with the ones I get in 32bits, I notice that in 64bits I get only a sigle underscore after "imp"

In my code, I use an external module named AANDIA by using the following command:
USE AANDIA

This module is defined by a aandia.mod file made for 64bits

I use the Intel Fortran Compiler 10.0

[mecej4]

The conventions for name decoration are different on W32 and W64. The details are spelled out in the Fortran User Guide.

A USE statement only provides information to the compiler that helps it to compile. The object code of the subprograms that are so USEd is not contained in the .mod file, but in one or more .OBJ, .LIB or .DLL files, which need to be specified at link time. Failure to specify these files will result in unsatisfied externals, even after the compiler has read and digested the .MOD file.

If the missing object code is in a DLL, you will need the stub library for the DLL. This stub library should be provided by the builder of the DLL, but it may be regenerated using module definition files if necessary.

[sebastien_jaffre]

What I don't understand is the fact that some external symbol respect the convention you mention, and other not.

I've made dumpbin files on the .lib and .dll files for the 32bits and the 64bits (see the attachments) and I notice this:
In the dll files: some external names have a new leading underscore in 64bits (in my case my trouble concerns _aandia_mp_a and _aandia_mp_ia)
in the lib files: some external names have still a leading underscore in 64bits (same list of names)

And finally I don't know what is a "stub library", could you indicate me how to get this file?

[mecej4]

As to the name embellishment scheme, see the following section of the User Guide:

Programming with Mixed Languages:
Adjusting Naming Conventions in Mixed-Language Programming:
Procedure Names for Fortran, C/C++, MASM

A stub library is a library which, instead of containing code for external subprograms, contains information on where the code may be found in the matching DLL. Such a stub library is normally a by-product of linking .OBJ files to create a DLL. For DLLs whose stub library is not available, it is possible to create the stub library using module defininition files and the librarian LIB.EXE:

Microsoft MSDN page describing import libraries

[sebastien_jaffre]

I asked the person who has created the library provided the module (AANDIA) I want to use and it appears that this library has been compiled with a different version of intel compiler (9.1 versus 10.0 for me). Do you know if there is a "portability" of the .mod file between version of intel compiler?

If not do you know a way to modify something to keep the compatibility without the version 9.1 and without the source file of this library? I only own the dll file and the mod file compiled in the version 9.1...

[Steven_L_Intel1]

Generally, .mod files are "upward compatible", so you can use them in newer compiler versions. But 9.1 had a bug in the way it "decorated" some names for Intel 64, which can create an incompatibility for newer compilers that fixed the bug.

You can resolve this with your own declaration of the thing being imported - is it a variable or routine? Can you get the declaration of it from the developer?

[sebastien_jaffre]

Thanks for your reply, the thing imported isvariables (named "A" and "IA") and not a routine but I don't know if this module provides routine too. As this library is provided by external commercial tools (LMS) I don't have the declaration of this module. I'll try to ask the developer team of LMS in order to get only the declaration of this particular module.

[Steven_L_Intel1]

Yes, the problem applies specifically to module variables. See if you can get the declarations of those variables and I'll help you with the solution.

[sebastien_jaffre]

According to LMS, this module is compiled with a main solver .dll, therefore it is not possible for a user to make modifications to this module and then incorporate them in a user defined subroutine. To modify this module, they say I would need to recompile the entire solver which is not possible (I need to get the entire source files...)
Do you think I need to compile the entire solver? I belived that only the declaration part was needed, I means the following exemple:
MODULE XXXX
INTERFACE
FUNCTION...

END INTERFACE
END MODULE XXXX

[Steven_L_Intel1]

Normally, global symbols on Intel 64 architecture systems do not have a leading underscore - old compilers were sometimes putting one there when it didn't belong.

You can change the external name with your own declaration of the symbol, for example:

interface
subroutine foo
!DEC$ ATTRIBUTES DLLIMPORT, ALIAS:"_FOO" :: foo
end subroutine foo
end interface

If it is a module variable, you have a bit more work to do but it is possible.

It is not clear to me which symbols are giving you trouble and what the mismatch is. Do be sure that you are linking against the correct (32-bit or 64-bit) libraries.