LabVIEW
C++ build error with LabVIEW DLL
Solved!
Poop Loops wrote:I don't understand that last part of your post, about native LabVIEW data types. Does that mean I would only need those extra library files if I wanted to directly work with int64 or float32 or something?
But I'll stick the DLL in the build directory, as I distinctly recall it being different from my source directory. Thanks again. 🙂
By the way, I have spent maybe 10 hours now trying to simplify a problem that would have taken maybe 2 hours to do the hard way. 😉
No I'm not talking about skalars here. LabVIEW may call a single float32 and a double float64 but that is only preprocessor magic as far as the C compiler is concerned. What I'm talking about is when you pass arrays or strings to a DLL and select to use the native LabVIEW handles instead of C pointers to do so.
Those handles need to be allocated, resized and deallocated using the LabVIEW memory manager or things go bad very fast. As long as you do not pass such datatypes to your LabVIEW DLL (and don't want to use any other LabVIEW manager functions for whatever reason) you do not need to link in the labview.lib in your application.
As to the time spent on trying to simplify things it is apparent that you did not really know much about DLLs and different C compilers at all, so no surprise there that going that route took you a lot of time 
Rolf Kalbermatter
rolfk wrote:No I'm not talking about skalars here. LabVIEW may call a single float32 and a double float64 but that is only preprocessor magic as far as the C compiler is concerned. What I'm talking about is when you pass arrays or strings to a DLL and select to use the native LabVIEW handles instead of C pointers to do so.
Those handles need to be allocated, resized and deallocated using the LabVIEW memory manager or things go bad very fast. As long as you do not pass such datatypes to your LabVIEW DLL (and don't want to use any other LabVIEW manager functions for whatever reason) you do not need to link in the labview.lib in your application.
Ahh, I see. So all I'll be doing is taking data that LabVIEW acquires, crunching the numbers, and then giving LabVIEW a single number to pass to my instrument, so no pointers should be involved. But in any case, all I need to do is link labview.lib to make it work, right? So that's not too difficult. And it works perfectly now, by the way. 😄
@rolfk wrote:
As to the time spent on trying to simplify things it is apparent that you did not really know much about DLLs and different C compilers at all, so no surprise there that going that route took you a lot of time
Rolf Kalbermatter
Yeah, I only really had experience with small Visual Studio programs with 3 or so files at most and no DLLs, and then gcc used in Linux, but there had all my libraries in the system folders, so I never ran into that problem. That was really it, the DLL I made wasn't in the right folder. 🙂
Poop Loops wrote:
Ahh, I see. So all I'll be doing is taking data that LabVIEW acquires, crunching the numbers, and then giving LabVIEW a single number to pass to my instrument, so no pointers should be involved. But in any case, all I need to do is link labview.lib to make it work, right? So that's not too difficult. And it works perfectly now, by the way. 😄
In that case you shouldn't even need labview.lib. Not bad if you have that in your project since Visual C is smart inough to only pull in any object modules from libraries if there is any link reference to the actual symbol(s) in that object module anywhere in your compiled project. So if you do not use LabVIEW manager calls it will not link in anything from labview.lib eventhough you have that file in the linker settings explicitedly specified.
I do like to make my linker settings as mean and lean as possible so I usually do clean them up as it can sometimes help find problems when you later on make seemingly small changes that suddenly try to pull in symbols you are not really prepared to have been pulled in.
Rolf Kalbermatter
