01-03-2008 09:27 AM
01-03-2008 10:59 AM
After some more analysis, I realized that one of the CINs is using a memory manager function:
#ifdef DOUBLE_PRECISION
if (err= NumericArrayResize(fD,1L,(UHandle*)&newData,*newNpts)) goto out;
#else
if (err= NumericArrayResize(fS,1L,(UHandle*)&newData,*newNpts)) goto out;
#endif
I suspect that this may be related, but still am not sure of the solution.
01-03-2008 12:56 PM
Well, all invocations of the exported external code functions among which the memory manager functions are too, need to link back to the LabVIEW core that called the according C code directly or indirectly. This is done in the labview.lib file that is linked into every CIN but there is a potential problem for LabVIEW DLLs, since the DLL is invoked by a non-LabVIEW process and that DLL only indirectly links and loads the LabVIEW runtime engine in which the LabVIEW VIs inside the DLL are called.
@TBonanno wrote:
After some more analysis, I realized that one of the CINs is using a memory manager function:
#ifdef DOUBLE_PRECISION
if (err= NumericArrayResize(fD,1L,(UHandle*)&newData,*newNpts)) goto out;
#else
if (err= NumericArrayResize(fS,1L,(UHandle*)&newData,*newNpts)) goto out;
#endifI suspect that this may be related, but still am not sure of the solution.
01-03-2008 01:31 PM
Thanks,
I'll try linking the CIN using labviewv.lib from the current version of labview to see if this resolves the issue.
01-03-2008 04:11 PM
Problem solved. The original code resource was built against Labview 6.1. Once I figured out how to do it, I recompiled the C code against the Labview 8.2 CINTOOLSDIR using the existing LVM (labview make file). After reloading the code resource to the CIN node, I rebuilt the shared library and the new DLL loads without errors.
I could not see how to explicitly link Labviewv.lib instead of Labview.lib, but it seems this is somehow handled automatically.
Thanks to rolfk for pointing me in the right direction.