LabWindows/CVI

cancel
Showing results for 
Search instead for 
Did you mean: 

Using a stand-alone CVI .so library in Linux

Solved!
Go to solution

I am unsuccessful loading a cvicc compiled .so library from another application in Linux.

 

Specifically, I was first were stuck on the RTE error “cannot find the UIR file”.  Passing an executable file path (a test host program) in argument two of InitCVIRTE() (a "synthesized" argv[]) solved this problem, but now I get the RTE error that it “cannot find the callback files”.  I HAD to pass a CVI compiled executable file path, passing the .so file path wouldn't work.  Things work only if InitCVIRTE() is called from a CVI compiled executable, and not from the .so library.  

 

Loading the library and making function calls from a cvicc compiled executable works fine when the above rules are followed.  I just can't get the library to lwork with an non-CVI compiled application, which is my goal.  It behaves as though the CVI Runtime Engine only supports CVI compiled executables and not “stand-alone” libraries.

0 Kudos
Message 1 of 6
(4,226 Views)

You need to create a source file with the callback tables for your project and then add it to the make file for your non-CVI compiled application.

 

You can create the callback table file in the Build>>External Compiler Support dialog in the CVI ADE.

 

Luis

0 Kudos
Message 2 of 6
(4,200 Views)

Thanks for your reply!  Alas, I don't believe I have the capability of doing what you suggest.  I'm trying to integrate into a proprietary IDE on a LTX-Credence mixed signal tester (Envision).  It compiles and runs the code from the IDE, there is no makefile.  I was hoping to simply load the library, they provide a call to do this, I've done this in a Windows environment (Visuall C++) with this same project without a problem

 

It puzzles me why I can't get the RTE to look in the .so library I'm loading to resolve these references.  I expected it to work when I passed the .so filepath to the InitCVIRTE() call, but no such luck.  It will only work with a executable file path and when called from an executable.

 

 

 

0 Kudos
Message 3 of 6
(4,194 Views)

Hello PDX_Doug,

 

I don't know the details of how your ADE is using the library, so I might be missing some important detail, but what I can do is to try to explain what is going on inside the LoadPanel function call, which is the root cause for this error (if I'm assuming correctly). Maybe this will help find a way to get arond the problem.

 

Inside the LoadPanel function call, the CVI runtime engine needs to convert the callback names that are specified in your .uir file into function pointers that it can call when an event occurs for those controls. This is done in by performing a look-up in a table such as the one created by the External Compiler Support dialog in the CVI environment. When you link your executable or library in the CVI environment (or with cvicc in Linux) this table is automatically linked into your binary, so you don't need to do anything special. But when you link your application with an external compiler, you need to make sure that you supply this callback table as an input into your build, either as source code or as an object file, so that the linker can include it in the final image of the application.

 

By the way, I'm about to go on vacation for a couple of weeks, so I won't be able to reply for a while. But I'll be happy to follow up when I get back.

 

Luis

0 Kudos
Message 4 of 6
(4,175 Views)

Hi Luis,

 

Haven't replied since I knew you were out.  I've been working with NI Support on this, nothing definitive yet.  My turn for some time off, I'll let you know where things are when I get back in a week.

 

Doug 

0 Kudos
Message 5 of 6
(4,109 Views)
Solution
Accepted by topic author PDX_Doug

A series of exchanges with NI support finally came to a resolution on this!  Ended up adding a dlopen() call with the RTLD_LAZY|RTLD_GLOBAL flags inside the library to load itself before calling InitCVIRTE(), RTLD_GLOBAL being the key.   The man page for dlopen() best explains why this worked.

 

Thanks for your responses Luis!

 

Doug

0 Kudos
Message 6 of 6
(4,019 Views)