C++ build error with LabVIEW DLL

[Poop Loops]

Hi, I'm a student at UC Irvine learning to use LabVIEW.  I am working on a practice project for which I have to use a PID system to control the temperature of an object.  Things are starting to get a little messy with nested control statements, loops, etc., so I figured I'd export a LabVIEW DLL with all the hard to code stuff, such as interfacing with my instruments, and plotting data or whatever, and do the number crunching and keeping track of stuff in C++.

The DLL file I made in LabVIEW went off without a hitch as far as I can tell, but when linking it to my C++ test program (which at this point is just including the LabVIEW's .h file for the DLL and an empty main() function), I get a lot of build errors.  I am using Dev-C++ which uses g++ to compile the code.

Here is a pic of my build errors:

[Vivek_N]

As the problem does not lie in the LabVIEW VI/DLL itself, I think the problem may be with the way you have called it from within C++. Apart from including the right header file, have you included the library file creating in LabVIEW in your C++ project? Please refer to the following knowledgebase article to verify this: http://digital.ni.com/public.nsf/allkb/70995EC2CA1B523386256DD4004F3DE6?OpenDocument .

I hope this helps. 

[Poop Loops]

Right, those are the exact directions I followed.  I told my IDE that there are library functions in the cintools folder, and when that didn't work, I just copied all those files over to my working folder.  I'm probably still missing something...

Oh!  But when I first tried to compile this stuff, it spit out two errors, one saying it can't figure out which processor I'm using and the next one saying it can't figure out which compiler I'm using.  I had to force x86 by editing the .h file (it was the file that's basically dedicated to those two things... started with a p is all I can remember 😞 ) and GCC wasn't an option for Windows OS'es, so I just copied it over from the Linux and I think Mac sections.

I had been getting the errors about int64 not making sense the whole time, so I don't think I messed it up more.  I figured x86 is a safe bet (these are school computers) since the OS is 32bit anyway.

But yeah, I'll get back to this tomorrow and double check that I'm linking everything correctly.   Thanks for replying, by the way.  I thought this thread was pronounced dead already. 🙂

[rolfk]

You do not want to link with the libraries in the cintools directory but with the lib file that was created alongside the LabVIEW DLL. Your project needs to know how to interface to that DLL and that could be done by doing LoadLibrary() and GetProcAddress() explicitedly on that DLL, but much easier is to simply add the lib file that LabVIEW created for you alongside the DLL, into your Visual C++ project.

Rolf Kalbermatter

Message Edited by rolfk on 07-29-2009 10:52 AM

[Poop Loops]

I'm using Dev-C++, but yeah, I did ad myDLL.lib to the project.  All I did was click on my project, go to "import", and select that .lib file.  I don't know if there's more that I have to do.

[rolfk]

Ahh Dev C++! Do you mean the one from Bloodshed software based on the mingw toolchain? It may be a problem with the mingw toolchain not recognizing the lib format as created by LabVIEW. That lib is formatted in COFF format for MS Visual C.

And if you use the cygwin based toolchain it will surely not work with COFF format libraries.

Rolf Kalbermatter

Message Edited by rolfk on 07-29-2009 05:46 PM

[Poop Loops]

Yes, it's the Bloodshed one.  Awesome, at least I know what the problem is now.  I'll just get a student version of Visual C++ installed on that computer and I'll see if things clear up.  Thanks a lot for your help, everyone! 😄

[smercurio_fc]

Would the Visual C++ Express Edition from MS work for you? I'm not sure what else you're doing, but the express editions are free.

[Poop Loops]

That's actually what I downloaed earlier today.  I am now having an error about not being able to find the .DLL file.  I re-created the .DLL file from LabVIEW, it, the .h, and the .lib files are all in the same folder as my source code, and everywhere I could find something asking about a pathname (i.e. resources, headers, etc.) I added both the source folder and the cintools folder.  I also included the .lib file into my project, both from right-clicking my project and going to add -> existing item and by going to project properties -> linker and one of those had something about "additional resources" or something, so I added my .lib file there too (found something online saying to try that) Same error.

But at least it compiles now. 😄

All I'm doing now is calling one of the functions from the DLL and displaying its output on the screen.  Without that call, the program can run fine, but of course then it isn't trying to find the DLL file in the first place.  Oh, another thing I did was just convert all 10 lines of my code over to C from C++ and tell the compiler to compile it as C code, but that gives me the same error.

So I really don't know what else to do at this point. 😞

[rolfk · Accepted solution]

Normal windows apps are not as forgiving about where you can put your DLL as LabVIEW. You have to have a DLL either in the direcotry where the executable file itself resides (that would be your build directory, not the source directory), the windows or system directory, or any directory that is set in the PATH environment variable. Anythin else will most likely not work, or at least not reliably.

No need to add the cintools directory into your include file paths nor the library file paths. you would only need that if you decided to let the DLL export native LabVIEW data types in which case you would need the LabVIEW manager functions to prepare the correct data buffers.

Rolf Kalbermatter

Message Edited by rolfk on 07-30-2009 07:49 AM