LabWindows/CVI
"undefined symbol" error while using a custom instrument driver
Hi JR,
I would like not to distribute an additional DLL and have the code included in the executable instead.
Nevertheless, I made a fast try switching the target type to DLL, including the import library for the thirtd party dll in the project and creating the library: the linker now complains only about WinSDK functions 
The strange thing is that this same code perfectly works while included at source level in target application project!
I don't understant what's different between these two scenarios...
Work in progress...
Of course I was missing the relevant SDK lib... Now the DLL compiles and links ok. 
It remains unknown why I cannot link the project if including the instrument at code or lib level: the import libraries for both third party dll and SDK calls are already included in the project, so... why? 
I have encountered a similar situation when using MS Visual Studio. I tried to generate a static library which incorporated other third-party (import) libraries but the final link stage of the end application still wanted to reference the third party libraries. Apparantly it is possible to configure Visual Studio so that the intermediate static .lib file contains all the relevant information (and so would not require the final application to need all the libraries) but this is not standard behaviour and I never bothered to investigate further.
It seems that the CVI linker is proceeding along the same lines, but I'm less confident that its behaviour can be altered. We need to wait for Luis to log on 
JR
Being waited on to log on... how flattering
I wish I had a simple and obvious solution, but I don't.
The problem in this case is that, whereas DLLs (via their import libraries) carry no additional build-time dependencies to their clients, that is not the case with object files and static libraries: any project that uses those .obj and .lib files must satisfy all of their dependencies when that project builds.
There is a mechanism, with .fp files, to advertise such dependencies to the clients of the .fp, and that is the auto-load list (Edit>>FP Auto-Load List, in the function tree editor). The caveat, however, is that these indirect dependencies must have a companion .fp that you can add to this list. And in your case, you don't have one. So the only solution I can think of is for you to create a very thin wrapper module where you would wrap all of the SDK functions that you need, then create a basic .fp for this wrapper -- you can do this semi-automatically, from the header file (Options>>Generate Function Tree) -- and then add this .fp to the auto-load list of your primary .fp. And then you'll probably have to create a second .fp wrapper for your other dependency (a non-SDK third-party DLL?).
Once you have declared the dependency chain for this .fp, you should then be able to use it on any test application and CVI should know to link in these additional static libraries whenever it builds the test application.
If you choose to go this route, you'll probably have to deal with a bunch of non-standard data types in the parameters of the SDK functions. I don't remember if these are automatically added to the .fp when you create it from the header file. If not, all you need to do is add them to the .fp later (Options>>Data Types, from the function panel editor). Don't worry about providing the definitions for these data types. They're not necessary. You just need to make sure that their names are in the list.
Luis
Hello Luis, thanks for giving this a trial.
Based on your words I suppose I will split down the instrument and proceed step by step:
- A first instrument with my functions only: I had no errors on these functions so I suppose this will go on immediately
- A second instrument for the third party dll: I'll try to create the wrapper to the dll and have the instrument built on top of the wrapper. I hope I have no problems in doing so
- A third instrument with the wrapper to SDK function, if and when you can explain how to address linking problem. If not I'll continue directly calling these functions from the code as I have done till now.
This approach should permit me to have part of the job completed and reusable in my applications. As far as other steps are completed, I'll proceed integrating them in my actual code; in the meanwhile I'll continue directly coding these functions as I've done till now.
I've always been a fan of "the simpler the better" 
