Need basic image processing, but only have Linux

[mjstone · Accepted solution]

Well, I never managed to get LabVIEW talking to a non C/C++ language, but I managed to make my C++ wrapper work. If you want to wrap a 3rd-party C++ library for use with LabVIEW, you must link it into your wrapper STATICALLY, not dynamically. Apparently, as soon as LabVIEW has to load more complicated C++ functions dynamically into memory, it refuses to work, even if you don't call those functions directly. This at least applies to Linux. Consider this solved. Is there any place I can put this information for future users? (Or maybe NI could just fix this silly bug)

[NateTheGreat]

Hmm, thanks for that. I might be using C in Labview soon.

[mjstone]

C shouldn't be a problem, actually. It's only C++ where you need static libraries.

[rolfk]

That doesn't have to be a problem either, but you do need to have the according runtime support installed on all machines you intend to run such libraries and that can get complicated. Also note that the C++ ABI is highly different between different compilers and even can vary between different versions of the same compiler so trying to link to C++ shared libraries created in a different version of the compiler used to create your exececutable or shared library is a sure way to run into all kinds of troubles.

All these things are in fact completely independant of LabVIEW and will happen in any application. The only extra complication might be that LabVIEW is itself written in C++ and of course uses the dynamic C++ runtime libraries that come with the compiler used to create LabVIEW. This might potentially clash with the dynamic runtime library used in your C++ DLL. SxS DLL handling in Windows XP SP 3 and newer should eliminate such problems, but SxS is in itself a horrible hack that is sometimes worse than the DLL hell it was meant to cure.

As far as Linux shared library support goes you would need to give to the gcc linker step the actual sonames it should reference to resolve the dependant C runtime libraries. Otherwise it will resolve to whatever *.so happens to be in memory and export the required symbols and that might be a very different version than what your code was compiled against.