32 vs. 64-bit Compiler/Linker

[rdvsea]

I got my program to compile and link on x64 alright. When I however change the compiler/linker to Win32, I getthe followingerror (while linking):

1>Linking...

1>abcd.obj : error LNK2019: unresolved external symbol _ABC@12 referenced in function _DERABERR

1>Release/rd6864.exe : fatal error LNK1120: 1 unresolved externals

This same code compiled and ran fine in CVF 6.6 as well.

Any thoughts on what might be going wrong? Is this a bug in the program itself which just gets overseed by the x64 (and the CVF) compiler but one which the IVF Win32 compiler captures?

Thanks.

[TimP]

unresolved external symbol _ABC@12 referenced in function _DERABERR
An object may not have been rebuilt, or, in effect, /iface settings may be inconsistent among your objects. You could see that with dumpbin /symbols. Presumably, if you didn't have problems in CVF, you don't have argument list mis-match.

[rdvsea]

Quoting - tim18

unresolved external symbol _ABC@12 referenced in function _DERABERR
An object may not have been rebuilt, or, in effect, /iface settings may be inconsistent among your objects. You could see that with dumpbin /symbols. Presumably, if you didn't have problems in CVF, you don't have argument list mis-match.

The only change between the two sets of compilation was that in the Configuration Manager, I changed the Platform from x64 to Win32. When it is x64, no problem. With Win32, I get the above error mesg. For both, I manually went into the directories (Release) and deleted all the .obj files before compiling (and linking).

[Steven_L_Intel1]

Please rigjt click on the project, select Properties, Intel Fortran, External Procedures. Change the calling convention to "default" and the string length argument passing to ". Rebuild the solution.

Normally, you would not have a problem with this. Projects converted from CVF have CVF-compatibile defaults selected and as long as they are consistent, it all works. It seems that somehow you have a mix of settings - not sure how that happened.

Let me know what happens.

[rdvsea]

Quoting - Steve Lionel (Intel)

Please rigjt click on the project, select Properties, Intel Fortran, External Procedures. Change the calling convention to "default" and the string length argument passing to ". Rebuild the solution.

Normally, you would not have a problem with this. Projects converted from CVF have CVF-compatibile defaults selected and as long as they are consistent, it all works. It seems that somehow you have a mix of settings - not sure how that happened.

Let me know what happens.

As you said, I changed the calling convention to "default" [it was CVF (/iface:cvf) previously]. But, I did not see any "inherit from project default" for the string length argument passing though. The only options were:

* After All Arguments;

* After Individual String Argument (/iface:mixed_str_len_arg)

I left it at what it was before -- After All Arguments.

I rebuilt the solution using both the Win32 and x64 configurations -- both compiled and linkedfine. Thanks for your help.

For my understanding, could you highlight what these changes actually did to make the compilation and link work?

[Steven_L_Intel1]

Without seeing your project, I don't really know. I can tell you that on IA-32 there are two different calling conventions, C and STDCALL. CVF used STDCALL by default and IVF uses C by default. Both have various ways to use the other. In your case, you had a call to a routine where STDCALL was being used as the default, but the source defining the routine was compiled using C as the default. I'm not sure how you got to that state. The key is to be consistent - and if you ever see someone (or try to do it yourself) use ALIAS to rename the external to do away with (or add) the STDCALL @n suffix, stop right there as that will be a big mistake.

Steve

[rdvsea]

Thank you, Steve.