NI DAQmxBase OpenSUSE Dynmaic Load of libnidaqmxbase.so not Working Correctly

[SimonSparkes]

I am trying to use NI DAQmxBase 14.0 on OpenSUSE 13.1 via a C++ class that dynamically loads the shared library (libnidaqmxbase.so) at runtime and maps the various calls that I need including CreateAIVoltageChannel, The reason for doing this is that sometime the code will run on a machine with the drivers and libraries installed and sometimes not.

When I test this with a machine that has the drivers installed but no NI card in I get random results depending on how the program is linked.The program is a simple console app that calls getDevSerialNum on device names.

If the program is linked with the shared library (using -lnidaqmxbase) then the program runs successfully. If the program is linked without the shared library (no other code changes) the program runs but does not correctly return the device serial call (it should return an error but does not).

My assumption is that there is some special initialisation code that should be called to correctly initialise the library. Any ideas?

[aevans2]

Hi Simon

Is the attachment written by yourself or is it provided by NI?

[mattsnow]

Hi SimonSparkes, 

This sounds like quite an involved issue and from an initial search the only possibly related material I could find is this Knowledge Base article: 

http://digital.ni.com/public.nsf/allkb/230EC551B55535E886257097004F7A62?OpenDocument

Is it not possible to guarantee that the machines you will be using will have the drivers and libraries installed? Is the code you have uploaded something you have written yourself or is it an edited example? 

Apologies as I'm not overly familiar with DAQmxBase or Linux in general. 

Kind regards 

[SimonSparkes]

The code is something I have written. Will try and produce a test case and upload the source code as the extract I posted is part of bigger system. Have looked in the API for init functions for DAQmxBase, but there are no listed but it did occur to me overnight that I might try scanning the library symbols for possible functions.

[mattsnow]

Attached is an example that may be what your looking for. 

This uses something called the #error Directive that you can read more about here:

https://msdn.microsoft.com/en-us/library/c8tk0xsk.aspx

Please let me know if this helps you with your issue. 

Kind regards 

[JoeFriedchicken]

---

SimonSparkes wrote:

I am trying to use NI DAQmxBase 14.0 on OpenSUSE 13.1 via a C++ class that dynamically loads the shared library (libnidaqmxbase.so) at runtime and maps the various calls that I need including CreateAIVoltageChannel, The reason for doing this is that sometime the code will run on a machine with the drivers and libraries installed and sometimes not.

When I test this with a machine that has the drivers installed but no NI card in I get random results depending on how the program is linked. The program is a simple console app that calls getDevSerialNum on device names.

If the program is linked with the shared library (using -lnidaqmxbase) then the program runs successfully. If the program is linked without the shared library (no other code changes) the program runs but does not correctly return the device serial call (it should return an error but does not).

My assumption is that there is some special initialisation code that should be called to correctly initialise the library. Any ideas?

---

Hi Simon,

This is a known bug in the LabVIEW 2012 Run-Time Engine, upon which the DAQmx Base 14.0 C API is built.

If you add LD_DEBUG=all to your environment before running your executable, you'll see why. In short, the LabVIEW Run-Time Engine's shared objects don't fully advertise all of their dependencies, which causes ld to fail finding all of the symbols.

The workaround is to create an intermediate wrapper library that uses -lnidaqmsbase when built and only using dlopen to load it on systems that have the driver installed.

My team has been working on a fix with LabVIEW, and if you're interested in joining the DAQmx Base 2015 Beta Program, please send me a direct message with your email address.

[aevans2]

okay, just wondering how you're compiling it aswell

[SimonSparkes]

Hi Joe,

Tried the workaround of creating a wrapper dynamic/shared library, linking it with the nidaqmxbase library at link time and then dynamically loading the wrapper at runtime, however this had the same results.

I did an nm of /usr/local/natinst/nidaqmxbase.so.14.0.0 which seems to have no symbols, but the /usr/local/natinst/nidaqmxbaselv.so.14.0.0 has all the symbols I expected to see in the non lv version. Not sure how to explain this.

What I did see was a DLLInit call, however this does not seem to exist in the non lv version of the library. Is there some kind of init function I can call in the DLL?

[JoeFriedchicken]

---

SimonSparkes wrote:
 

Tried the workaround of creating a wrapper dynamic/shared library, linking it with the nidaqmxbase library at link time and then dynamically loading the wrapper at runtime, however this had the same results.

---

This surprises me since another customer was able to use this technique. Their end goal was interoperating with a Java application, so perhaps the dynamic loading in that environment is just different enough to make it work.

---

SimonSparkes wrote:

What I did see was a DLLInit call, however this does not seem to exist in the non lv version of the library. Is there some kind of init function I can call in the DLL?

---

No, the LabVIEW Run-Time Engine doesn't advertise its dependencies correctly in the 2012 release. Unfortunately, asking a buggy run-time to load or initialize itself doesn't serve as a workaround.

I would say the best course of action would be to join the DAQmx Base 2015 beta program, and see if the improvements serve your needs.

[SimonSparkes]

Joe have tried to send you a private message with e-mail address for joining beta program, but not sure if you've seen it as I have not had a response yet.