Need help with preprocessor definitions in the Import Shared Library Wizard

[MinerHokieRamp]

I'd like some help with the preprocessor definitions window.

The Wizard says none of the functions in the library file were found in the header file and also says that the following three 'symbols' are undefined for the aceSetMetrics function: S16BIT, U16BIT, and _DECL

I backed up in the Wizard and tried the following in the preprocessor window for S16BIT and U16BIT, not having a clue what to try for _DECL:

S16BIT = int16; U16BIT = uInt16

After another attempt, all three 'symbols' are still undefined.

The header file is attached (I deleted all functions but the one I chose for troubleshooting).

Thanks,

Jeff

[Jordan-G]

Hi Jeffery P,

Is the shared library you are trying to import compiled from object oriented C++ code? If so, you will need to write a C style wrapper DLL before you try to import the shared library. Here is a KnowledgeBase article that hleps explains why the error of undefined symbols is thrown.

Regards,

Jordan G. 

[nathand]

Is that function supposed to be a prototype for a callback, rather than a function you call directly? If so, you cannot make it work in LabVIEW. Search this forum for callbacks and DLL. You'll need to provide your own function, written in C or a compatible language, that can pass data to LabVIEW and act as a callback.

[MinerHokieRamp]

Background:

The LV code was working in LV2009; the code contained LCFNs.

This code was causing LV2013 to crash. I changed the calling convention in all the LCFNs to 'stdcall' and the crashes stopped but most of the LCFNs started returning values that indicated issues in the DLL and/or the parameters sent to the functions. The company that wrote the DLL provided documents that describe the meaning of those returned values; however,the meanings are general/vague.

So, I decided to try the Library Wizard and ran into this issue. The basic issue involvesmaking LV2009 code run with LV2013.

Thanks,

Jeff

[nathand]

Can you share the code that worked in LabVIEW 2009, and doesn't work now? Also, can you share the entire header file, and the documentation?

Have you tried changing the error checking level to Maximum in the Call Library Function Node, to see if you get a more helpful explanation of the problem?

There have been some changes in the way LabVIEW handles Call Library Function Node. I thought those changes started in LabVIEW 2009, but maybe they were in a newer version. It may not be the same problem, but your issue sounds like what's described here (especially because your header file suggests the use of a callback function): "In LabVIEW 8.6, I bumped the error handling up from default to maximum for the suspect CLF node, and sure enough the 1097 error showed itself.  The problem turned out to be that the offending function requires a pointer to a callback function as one of its parameters.  Previously (via the clf node), I had been passing in a NULL for this parameter.  This "worked" in LabVIEW 8.6 with the error handling set to default but would not similarly "work" in LabVIEW 2010." You may want to read through that entire thread from the beginning to see if it helps.

EDIT: another thread says the changes were in LabVIEW 2010, not 2009.

[MinerHokieRamp]

---

@TheRealMichaelJordan wrote:

Hi Jeffery P,

Is the shared library you are trying to import compiled from object oriented C++ code? If so, you will need to write a C style wrapper DLL before you try to import the shared library. Here is a KnowledgeBase article that hleps explains why the error of undefined symbols is thrown.

Regards,

Jordan G. 

---

Assuming the shared library is compiled from object-oriented C++ code, is a C style wrapper required when using LV2013? (The KnowledgeBase articles refer to LV 8.x)

[rolfk]

---

@JeffreyP wrote:

---

@TheRealMichaelJordan wrote:

Hi Jeffery P,

Is the shared library you are trying to import compiled from object oriented C++ code? If so, you will need to write a C style wrapper DLL before you try to import the shared library. Here is a KnowledgeBase article that hleps explains why the error of undefined symbols is thrown.

Regards,

Jordan G. 

---

Assuming the shared library is compiled from object-oriented C++ code, is a C style wrapper required when using LV2013? (The KnowledgeBase articles refer to LV 8.x)

---

Not necessarily, depending how the developer declared the functions (or if he used a DEF file for declaration of the exported functions but that is not anymore recommended). The section of header file declaration you show is not fully conclusive. Your declaration of int16 and int32 is also not anymore accurate for recent LabVIEW versions. Generally it is better to work with the standard C types as anything else is likely to pose problems in some way.

Your header file or one of the other included files needs to declare the types including the _DECL and _EXTERN declarations, They are not standard C so need to be declared somewhere in the headers. Finding where is the cumbersome detective work for whomever wants to interface to external libraries.

Most likely _EXTERN resolves to something like "extern "C"" which tells among other things to the C++ compiler to export the function as standard C function without any naming decoration and other C++ firlefanz.  And _DECL probably resolves to either _cdecl or _stdcall, which would tell you the calling convention to use.

S16BIT is likely "signed short" and U16BIT is likely "unsigned short". But that is just an assumption (albeit a resonably educated one) until you have found the real declaration. I have seen code declarations that resolve to something completely different than the obvious type, for various reasons such as legacy code or also simply a crazy programmer. 😉