I am using LabView 2015 to import a canlib.so library written in C for some CANbus hardware (Kvaser)
and compiled on Linux (CentOS6), and the problem is, the Wizard tells me it cannot find 2 header files,
namely "canstat.h" and also "stdlib.h".
Now of course, I _did_ add the include paths (see figure) as suggested by the wizard,
but still no success. Counterproof: I inserted the whole canstat.h in the library canlib.h header,
in place of the <#include "canstat.h"> line, and now many more functions were recognized.
But I can't do that with stdlib.h!
There are many other includes, to uncountable nesting levels!
What can I do, and how is it possible that the Wizard does not work?
Thank you for any suggestion.
We have tried to reproduce your issue on CentOS and have not been succesful. Is the import wizards throwing any other errors? Is it possible for you to provide a copy of your code so that we can reproduce the issue on our side?
Can you try the following simple example and import it without issue?
Hi, and thank you for the answer.
I imported your sample right out of the box no problem.
Before, I spent really much time on the library I got from KVaser, see in attachment,
without finally getting to import all functions.
By trial and error I found that the order in which "struct"s appear in the header file
matters very much, and one cannot use in a header file a "struct" that did not
By trafficking with the main header file, reordering some include and modifying
some other headers I managed to import most of the functions, but never all of them.
So I concluded that the Import Wizard has limitations wrt to gcc,
and libraries more complex than a certain level not only cannot be imported
but generate false warnigs of "XXX header not found". Finally,
I gave up with LabView on this, and decided to read my hardware with
Thanks for the help anyway!
First, in C it is syntactically an error to use a struct definition that has not been previously declared. And yes that can be a pain in the ass with complex import hierarchies but that is the standard. If gcc has worked around that in some way then they have created a pretty advanced parser but it is not a requirement of the C standard.
The import library wizard definitely wasn't meant to try to parse arbitrarily complex C headers and translate them completely. It's already amazing at what it does, given the very limited information the C syntax actually allows for proper specification of all the intrinsicaties of calling a function. Many aspects of that such as proper buffer allocations, necessary pointer vodoo and such are simply not possible to extract from a header file but need to be deduced from the context of the function name, parameter name, certain common patterns, the actual prosa documentation of the functions and last but not least often by try and error (meaning run and crash).
In fact I feel the Import Library Wizard gives most users a wrong feeling of safety that it simply can't make true, given the limitations of C header files. I don't want to think how many LabVIEW libraries were created with the import library wizard and simply because it doesn't crash people assume it is all fine. It is almost never, except for the most trivial functions that only use skalar arguments or simple string input parameters. Anything else requires careful review afterwards, if all the various buffers are allocated to the necessary size, and if the function documentation mentions anything else that is special to each of those functions. Otherwise you end up with a software which does corrupt memory somewhere eventhough you very often do not receive an immediate error. Not every bad memory access is in a way that the CPU virtual memory manager can flag it as illegal access. It can also simply destroy memory that belongs to other more or less important parts of your process, including data buffers with measurements or information LabVIEW needs to manage your code properly. That often crashes only many operations later and seemingly has nothing to do with a specific external library call, but reality is that this bad call is the culprit.
Second, you can use external libraries without necessarely running the import library wizard or as in your case run it with what it recognizes and then continue from there. In fact I almost never use the import library wizard. It can be handy to quicken the creation of import wrappers for a shared library but the result is usually more than suboptimal. Besides that you really have to go through each function afterwards anyhow and review it to do in fact the right thing (TM) it creates for more complicated function calls either very involved code that can often be optimized a great deal or simply wrong code because of the limitations of what the C syntax can express. And besides, the icons and connector pane of the resulting library are also pretty ugly.