07-02-2009 12:57 PM
07-03-2009 12:00 AM
Are you using the precompiled binary package of the library ?
Then this a incompatibility between Labwindows/CVI and the compiler which was used to compile that binary package. Symbols names with double undescore are usually reserved for internal use of the compiler and provided by the compilers runtime library. I can think of two possible workarounds. Either try to compile that library from sources with Labwindows/CVI. Or mightbe ( you did't mention the version of Labwindows/CVI,you are using) a newer version of Labwindows/CVI also includes that symbol in its runtime library.
07-06-2009 08:59 AM
I recompiled the library using MS Visual Studio 9.0...I am now trying to compile the library with CVI but the library using the following inline function that is not compatible with CVI. I am using an evaluation version of CVI which ends today. Not sure where to go next.
#ifdef _MSC_VER
static INLINE long lrintf(float f){
int i;
_asm{
fld f
fistp i
};
return i;
}
#endif
The ultimate goal is to read J2K files...do you have any other suggestions?
07-06-2009 09:34 AM
the answer is right here in your code:
#ifdef _MSC_VER
this literally means: "if we are compiling this code using the Microsoft Visual C compiler"
when you are compiling with CVI, _MSC_VER should not be defined or the compiler will stop on any Microsoft specific extension, like Clpow() or inline assembly. check your project settings and build options to be certain that _MSC_VER is not defined, and check that there is an alternative if _MSC_VER is not defined.
note that, you can try compiling the library as a DLL if the option is available, then use the dll in your CVI project: this way, the dll will use its own runtime (mscvrt.dll in your system directory) and your application will use the cvi runtime.
07-06-2009 12:36 PM
I was able to compile the library to a DLL and use that instead...but one question...I had to put a copy of the DLL in the windows\system32 folder in order for it to work...Is there a way to specfy to CVI to load from another directory? I tried including in the project but that did not work...
BTW, thanks for all your help!
07-06-2009 03:25 PM
when loading an application, windows searches for a referenced dll in the application folder first, then on every folder specified in the PATH environment variable.d
my prefered place is the application folder: put the dll in the same folder as the exe file of the application, and you are sure to never overwrite an existing dll. also, it suppresses the need for an installer which will copy the dll to the system folder and an uninstaller which will delete the dll when the applicaiton is removed... last but not least: the system32 folder is already a dll mess, everybody copies anything into it, rendering this folder uncontrollable. by NOT adding your dll to this mess, you contribute to the sanity of every system which uses your application.
07-06-2009 03:33 PM
Thanks! I would prefer it in the same folder as the application. I'll give it a try.