stdcall in DLL function not recognized

[menchar]

I have a DLL with many functions, two of which I recently added.

Both have prototypes of the form 

INT DLLEXPORT DLLSTDCALL FunctionName (   ...

as do all of the exported functions in the DLL.

Both are included in an FP with all of the other DLL functions so as to allow the creation of a type library.

BUT when I go to build the DLL after having compiled the DLL source file using the MSVCPP compiler in release mode, I get a popup claiming that these two functions don't use stdcall calling convention, and that they shouldn't be included in the type library.

AND when I compile and build the exact same sources in debug or release mode using the native CVI compiler, I get no such error.

1.  I don't believe there's anything in error in the source file, header file,  or the  fp I've added to in creating these two added functions.

2.  How can the calling convention somehow be different for the same source code for the two compilers.

3.  Why is an error detected only for these two added functions and not the dozen or more original functions.

Menchar

Message Edited by menchar on 04-24-2010 02:31 PM

[menchar]

To follow up -

I re-selected the MSVCPP compiler as the release compiler (after having switched back to the CVI compiler) and the problem disappeared!?

I think there must be something not quite right in the type library processing in CVI 2009 when using an external compiler.

It's like some sort of funky state was persisting that didn't get cleared out/reset until the entire DLL was rebuilt using the CVI native compiler in release mode.

I am using the MSVCPP  config file      c:\Program Files\National Instruments\CVI90\VSCPP8.ecc      that shipes with CVI 2009.

I am not using pre-compiled headers.

I have Visual Studio 2005 Professional.

[menchar]

And to follow up again -

This behavior is repeatable.

I changed the signature of a function that was already in the type library while using the release mode compiler (MSVCPP) and again CVI did a popup complaining about the lack of stdcall on the modified function (which of course did still have the DLLEXPORT DLLSTDCALL decoration) .

The problem again cleared when I reverted to the CVI compiler and rebuilt the DLL, then switched back to the MSVCPP release compiler.

[Raj_V]

Hi menchar,

Is there any particular error code you are receiving when this popup appears complaining about the lack of stdcall? Also, if you could post the exact error message verbatim in this forum, I can look internally to see if this error has been seen before and if so what the fix would be.

[menchar]

To be clear, the .ecc file I'm using doesn't ship with CVI:  rather, CVI ships with a built-in template for MSVCPP 8.0 (Visual Studio 2005) from which the .ecc file is generated.

The .ecc file I'm using is the same as the template.  I've used the "optimize for speed" selection.

[menchar]

The error message is a confirm popup that says:

LabWindows/CVI Message

Can't create Type Library Info:

The function "TGF_FakeFunction" is in the function panel file, but it is not marked for export.

The prototype is:

INT DLLEXPORT DLLSTDCALL TGF_FakeFunction (VOID);

I use "symbols marked for export"   as the Exports option.

Thanks

[menchar]

Maybe there's a fundamental limitation in CVI that you can't use symbols marked for export with an external compiler in release mode?

I use "symbols marked for export" only because, as I recall, I kept having problems getting things to build if I used a header file (include file).

I'll try using a header file, but it does sort of beg the question as to why "symbold marked for export" is available as an option.

[Raj_V]

Hi Menchar,

Sorry for the delayed response. I have been in the process of trying to recreate the same error on my end but have been unsuccessful in doing this. Is it possible to get some sort of code snippet or sample project that exhibits this behavior so we can explore this a little further.

[menchar]

I don't have an easy way to do that, the original code is sensitive and I can't publish it.

For now, I'll simply switch back and forth with the CVI native compiler (LCC) whenever I need to change the signature of an existing exported function or add a new exported function to the DLL.  I haven't seen that the resulting code, once recompiled with LCC then back to the release compiler, fail to run in any way.

The available release mode compilers (e.g. Intel, Microsoft) are so compellingly better than LCC at generating code for the newer micros, I think developers are going to want to use these external compilers more and more in the future.

I know it's a tough deal to try to make the interface seamless, but I was a little alarmed at this error, since it seemed like it might be indicative of something seriously wrong.   I know I found out the hard way about 16 byte alignment LCC Vs. Intel when trying to use vectorizing optimizations in the Intel compiler, the builds sometimes worked, and sometime would blue-screen at execution time despite lack of build errors, I had a 50-50 chance of being aligned. 

I mostly wanted to see if this error was of the same sort, where I might eventually get blue-screened at execution time due to this after doing the work-around.