Library (.lib) file issue in CVI-2013

[Barry_Wealand]

We have a CVI DLL project that links against a vendor-supplied library (.lib) file. Under CVI-2012, this project builds fine with no issues. Under CVI-2013, the linker apparently can't resolve any of the symbols in this library. The library is clearly included in the project; I have even removed it and reattached it, but no help.

Are there any known issues of this kind associated with upgrading from 2012 to 2013?

[Barry_Wealand]

Are there any compiler options that cause it to produce more verbose output? During the link phase, it would be handy to know whether it can't find the .lib file vs. something is unacceptable about the .lib file.

[ShamWOW!!]

Hello,

When it comes to CVI 2013, there have been a large number of improvements to the compiler. That being said, some people have noticed that stuff that would work in previous versions now have errors or stuff that are "caught" by the 2013 compiler. This might explain some of the issues that you are seeing.

You can get a more verbose output by setting the warning level to "extended" or "all" which is shown more in detail in the following page.

Options»Build Options

http://zone.ni.com/reference/en-XX/help/370051Y-01/cvi/usermanual/prjbuildopt/

Could you show some screenshots of the error that you are seeing at compile time?

Best,

Shamik C

Applications Engineer 

National Instruments 

http://www.ni.com/support 

[Barry_Wealand]

Thanks for your suggestions! I tried the elevated compiler warning level, and this did indeed show a large number of additional compile-time warnings. The error in question occurs at link time, however, and no new information was provided for this part of the build.

Per your request, I'm enclosing a screenshot showing the error in CVI-2013. The exact same workspace / project builds correctly under CVI-2012.

[Barry_Wealand]

I have succeeded in building the project of interest by changing the "Default calling convention (32-bit)" (in the "Build Options" dialog) from __cdecl to __stdcall. Now the DLL links successfully.

In this DLL and others in the same family, we use "__declspec (dllexport)" in the declarations of our exported methods. Does this need to change if the default calling convention is set to __stdcall?

All of the other DLLs use __cdecl as the default calling convention. Will these other DLLs be able to interoperate with the DLL built with __stdcall as the calling convention?

[Barry_Wealand · Accepted solution]

Changing the "Default calling convention (32-bit)" to __stdcall seems to have solved this problem. I don't think the other questions I raised in my previous post are relevant. This appears to be the "accepted solution". Thanks to all for your assistance!

--Barry