error LNK2019: unresolved external symbol _SysStringLen@

[Intel_C_Intel]

Hi

I'm currently evaluating the latest version of Visual Fortran and I'm having problems with an unresolved external symbol error.

I've created a Fortran COM Server project and all seems to work fine until I try to define a property within the "hie" editor of type CHARACTER(*). The error apparently occurs in the automatically generated interface code (see snippet below) when trying to link to the external "SysStringLen" function which I believe is in one of the windows OLE/COM libraries. I've viewed the verbose linker output and it seems to locate the required library fine, so i'm a bit stumped as to the problem.

! Local definition of SysStringLen
interface
pure integer*4 function SysStringLen_Local(bstr);
!dec$if defined(_X86_)
!dec$ attributes default, stdcall, alias : '_SysStringLen@' :: SysStringLen_Local
!dec$else
!dec$ attributes default, stdcall, alias : 'SysStringLen' :: SysStringLen_Local
!dec$endif
use ifwinty
integer(int_ptr_kind()), intent(in) :: bstr
!dec$ attributes value :: bstr
end function SysStringLen_Local
end interface


I've only dabbled with Fortran prior to this project so i'm wondering if i'm forgetting to do something simple? BTW i'm building the project in VS2005

Any help most appreciated.

Darren

[Steven_L_Intel1]

This is a bug in the wizard, tripping across a difference between Intel Fortran and CVF. Until the bug is fixed you'll have to hand-edit the file and add the digit 0 after the @ in the alias.

[Intel_C_Intel]

Thanks for the tip.

Actually I found I had to add '4' to the alias instead of '0'. i.e.

!dec$ attributes default, stdcall, alias : '_SysStringLen@4' :: SysStringLen_Local

Using the zero resulted in the same problem. I scanned the linker output again and found another reference to '_SysStringLen@4' so I used it instead. Do you see any problem with this?

Regards,

Darren

[Steven_L_Intel1]

Sorry, yes, 4 is correct, not 0.

CVF had an undocumented feature that if the alias ended with @ that the compiler supplied the "correct" decoration number based on the number of arguments. That doesn't work with ifort but this bit of history didn't get taken into account when we redid the COM Server Wizard.