Link Error - Undefined symbol __imp__MessageBoxA referenced in labview.lib

[kmc]

I recently upgraded to CVI 8.5 and when I tried to recompile my .dll I am getting an   Undefined symbol __imp__MessagBoxA@16 referenced in "labview.lib" link error.  I did not use to get this error when compiling with CVI 8.2.  I have the Run Time Support set to Real-Time Only in my Target Settings (as I did before), if I change the setting to Full Run-Time Engine the link error goes away.  Does anyone have an idea of why I am now getting this error when I previously did not

Thanks,

Kevin C.

[herosphro]

Hello Kevin,

Are you are including the labview.lib file in your CVI project as mentioned in this KnowledgeBase article?  If not, that might be the root of the problem since the Full Run-Time Engine should recognize the native LabVIEW files and find them instead of requiring them to be explicitly listed.  If this solution isn't sufficient please post again and we can do some more work to get your problem fixed.

[kmc]

Hi John,

I am including labview.lib in my CVI project.  As I mentioned, I was able to compile with CVI 8.2 and the target settings set for Real-Time only without issue.  All I did was upgrade to CVI 8.5 and attempted to recompile and I started getting this linker error

Thanks,

Kevin C.

[herosphro]

Kevin,

It looks like the reason we get this error in CVI 8.5 is that the linking checks instituted in 8.5 are much more strict than 8.1 and prior.  The functions in labview.lib are not fully supported in Real-Time environments (they contain Windows-specific code) so that is why we now throw this error to make the user aware that they are calling into a library that contains unsupported functions.  In this case the MessageBoxA and LoadStringA are two particular culprits that PharLap doesn't support.  We have a Corrective Action Request filed internally here to help correct this issue, but there is not a permanent fix currently.  The CAR# is 45614 so if you want to check on its status in the future you can call in to NI support for that information.

Considering all of this, we need to figure out what course of action we want to take.  If we are deploying to RT, we can figure out what functions call into this library try to remove them since we are no longer able to port them to RT.  If they are necessary functions we might try to find some workaround to this issue but there is not pre-existing solution for this path.  Also, if it worked in 8.1 we might also be able to use the older version of CVI for now until this issue does have a more solid resolution.  Could you possibly give me a little more information about this DLL and how its being used and then we might be able to work around this.

[kmc]

John,

We link to labview.lib in order to use the NumericArrayResize function.  The dll was developed to execute on both RT and Windows.  When executing in the Windows enviroment we pass alot of data back to the calling VI for debugging and status.  For our RT applications which use the dll, there are streamlined functions which do not use NumericArrayResize, we have added some conditional disable structures in the VIs which call the dll to determine which method to call.  I think that I can change the dll to dynamically link to the dll (instead of statically linking) and then use function pointers to call the NumericArrayResize method or create a seperate dll for my RT applications and again use the conditional disable structures within the calling VIs.  Not sure if you have any other suggestions?  The other possiblity is to just reinstall CVI 8.1 and use it to compile.  Can I have 2 copies of CVI installed on my machine?  Are there any installation issues that I should be aware of if I decide to go back and reinstall the older version of CVI

Thanks,

Kevin C.    

[JonathanN]

Hi Kevin,

You can always have multiple versions of the CVI IDE installed on your machine but you will only have 1 version of the CVI RTE installed. This version will match the highest version of the IDE you have. 

In CVI 8.5, we added additional SDK linker checks to ensure that those SDK functions were supported on RT. There is a bug report that has been filed for this specific issue and that is the report that John mentioned. For a workaround in CVI 8.5, you should be able to remove (or just cut and paste to a different folder) user32_lvrt.lib in the <National Instruments>\CVI85\sdk\lib\msvc\ directory. So in your case, close CVI, move this file to some other directory, open CVI, then recompile your project. 

Let me know if this doesn't work.

Best Regards,

[kmc]

Hi Jonathan,

I tried removing user32_lvrt.lib and then recompiling and I get linker errors related to that lib.  For example failed to open external module, abort load of external library, and undefined symbols for the functions that are in that lib.  Is there some other setting that I a missing that needs to be disabled?

Thanks,

Kevin C.

[JonathanN]

Hi Kevin,

Well,I thought we would revert to looking for user32.lib instead if user32_lvrt.lib wasn't there but unfortunately my guess was incorrect. However, there is still hope by moving user32_lvrt.lib to a different directory, and then copying user32.lib into the same directory as the sdk libs and then renaming that to user32_lvrt.lib. I tested this on my end and it worked fine.

Let me know what happens!

Best Regards,