LabVIEW crashes in calling dynamically linked libraries

[elliot.ee]

I am using LabVIEW 7.1 for Linux.

I am interested in writing wrappers around Intel's OpenCV library. The Intel's OpenCV library contains image processing functions. I want to use LabVIEW in order to provide a "glue" for the OpenCV functions.

Using C, I wrote up edge.c which will display a OpenCV HighGUI (basically a GUI window) and wait for an event from the keyboard before closing. It is a very simple program. It compiles and executes correctly.

Using a Makefile, I created the Linux shared library .so file around it. A Linux .so shared library is the Linux's equivalent to the Window's DLL. I named the file edge.so .

When I use LabVIEW's Call Library Function Node, LabVIEW crashed. It just shut LabVIEW down automatically. It did not even display an error message which surprised me.

From the results of this forum message, I decided to write up a C wrapper around the .so file.

I wrote up the following code:

#include <stdio.h>

#include <stdlib.h>

#include <dlfcn.h>

int main()

{

   void *libhandle;

   int (*edge_func)();

   libhandle = dlopen("/home/elliot/opencv_code/edge_code/edge.so", RTLD_LAZY);

   edge_func = dlsym(libhandle, "main");

   (*edge_func)();

   dlclose(libhandle);

   return 0;

}

When I compiled and executed the code, it worked fine.

Since I want it to run in LabVIEW, I used LabVIEW's Code Interface Node.

I created a CIN and I have it auto create a C file.

I wrote the following code using the CIN:

#include "extcode.h"

#include <stdio.h>

#include <stdlib.h>

#include <dlfcn.h>

MgErr CINRun(float64 *Numeric);

MgErr CINRun(float64 *Numeric)

{

   /* Insert code here */

   void *libhandle;

   int (*edge_func)();

   libhandle = dlopen("/home/elliot/opencv_code/edge_code/edge.so", RTLD_LAZY);

   edge_func = dlsym(libhandle, "main");

   (*edge_func)();

   dlclose(libhandle);

   return noErr;

}

When I ran lvmkmf which is the LabVIEW function to create the necessary files, it created the necessary files and the makefile. I ran the makefile and it created the lsb file that is needed.

I used the CIN to call the lsb file. I ran the vi and again, LabVIEW crashed by closing the LabVIEW window without displaying any messages.

If anyone can help me, that will be great! I have no idea how LabVIEW is crashing without displaying any messages. I would assume when I used lvmkmf and the makefile to create the necessary files that it would catch any errors that it did not like. Did LabVIEW crashed because it did not like the call to display a GUI window?

[elliot.ee]

Attached is edge.zip . In this zip file are the following:

/build_all.sh = a simple build shell script that will take all of the c functions within the folder and create an executable
/edge.c = the original edge.c program that opens a HIGHGUI window and closes when you press the key
/edge = the executable edge.c program
/edge.so = the Linux shared library file that was created from the makefile
/edgecall.c = the C wrapper around edge.so
/edgecall = the executable edgecall program
/makefile = the makefile that creates the edge.so file and the executable edgecall
/test_edge.vi  = the vi that contains the Call Library Function that calls edge.so. This program crashes without displaying a message.

/edgecall_labview/edgecall_labview.c = the automatic C function that is created from the Call Interface Node
/Makefile = the file that is generated when you run the script: lvmkmf edgecall_labview
/edgecall_labview/edgecall_labview.c.lsb  edgecall_labview.lsb   edgecall_labview.w   = The files that are auto-generated from the LabVIEW Makefile
/edgecall_labview/edgecall.vi = The vi that contains teh Call Interface Node that crashes without displaying a message.

***
Note that you will need OpenCV to run the code. OpenCV can be downloaded from SourgeForge
Download the Beta 4 for Linux

[elliot.ee]

From doing ldd edge.so, the dependencies (at least on the Linux box at work) are:

        libcxcore.so.0 => /usr/local/lib/libcxcore.so.0 (0x40020000)
        libcv.so.0 => /usr/local/lib/libcv.so.0 (0x40117000)
        libhighgui.so.0 => /usr/local/lib/libhighgui.so.0 (0x401ce000)
        libcvaux.so.0 => /usr/local/lib/libcvaux.so.0 (0x401eb000)
        libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x40250000)
        libm.so.6 => /lib/tls/libm.so.6 (0x40304000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x40326000)
        libc.so.6 => /lib/tls/libc.so.6 (0x42000000)
        libdl.so.2 => /lib/libdl.so.2 (0x4032e000)
        libpthread.so.0 => /lib/tls/libpthread.so.0 (0x40331000)
        libgtk-x11-2.0.so.0 => /usr/lib/libgtk-x11-2.0.so.0 (0x4033e000)
        libgdk-x11-2.0.so.0 => /usr/lib/libgdk-x11-2.0.so.0 (0x40593000)
        libatk-1.0.so.0 => /usr/lib/libatk-1.0.so.0 (0x40601000)
        libpangoxft-1.0.so.0 => /usr/lib/libpangoxft-1.0.so.0 (0x4061a000)
        libpangox-1.0.so.0 => /usr/lib/libpangox-1.0.so.0 (0x4063b000)
        libpango-1.0.so.0 => /usr/lib/libpango-1.0.so.0 (0x40648000)
        libgdk_pixbuf-2.0.so.0 => /usr/lib/libgdk_pixbuf-2.0.so.0 (0x4067b000)
        libgobject-2.0.so.0 => /usr/lib/libgobject-2.0.so.0 (0x4068f000)
        libgmodule-2.0.so.0 => /usr/lib/libgmodule-2.0.so.0 (0x406c4000)
        libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0x406c8000)
        libpng12.so.0 => /usr/lib/libpng12.so.0 (0x40732000)
        libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0x40755000)
        libz.so.1 => /usr/lib/libz.so.1 (0x40773000)
        libtiff.so.3 => /usr/lib/libtiff.so.3 (0x40782000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)
        libXrandr.so.2 => /usr/X11R6/lib/libXrandr.so.2 (0x407c3000)
        libXi.so.6 => /usr/X11R6/lib/libXi.so.6 (0x407c7000)
        libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x407cf000)
        libXft.so.2 => /usr/X11R6/lib/libXft.so.2 (0x407dd000)
        libXrender.so.1 => /usr/X11R6/lib/libXrender.so.1 (0x407f0000)
        libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0x407f8000)
        libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x4081d000)
        libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x408fc000)
        libexpat.so.0 => /usr/lib/libexpat.so.0 (0x4094d000)

[elliot.ee]

It may also have something to do with the way we built edge.so from the makefile. Perhaps LabVIEW needs some additional commands in forming edge.so. This is what the makefile looks like:

CC = g++
CC2 = gcc
CCFLAGS=-fPIC -g -Wall
DLFLAGS = -ldl -rdynamic
TARGETS=edge.so edgecall
                                                                                                                           
all: ${TARGETS}
                                                                                                                           
edge.so: edge.c
        ${CC} ${CCFLAGS} `pkg-config --cflags opencv` -shared -Wl,-soname,edge.so.0 -o $@ $< `pkg-config --libs opencv`
                                                                                                                           
edgecall: edgecall.c
        ${CC2} -Wall -o $@ $< $(DLFLAGS)
                                                                                                                           
clean:
        rm -f *.so* edgecall

[elliot.ee]

Another interesting thing that I found was that when I called directly the function int cvNamedWindow(const char*name, int flags) from the highgui DLL in Windows by using Labview's Call Library Function node, it will do exactly what it is supposed to do. It will display the GUI.

However, when I do the same in Linux, it tells me that it cannot find the function within the library. When I ran the script nm -D, it displayed the function within the library.

Attached is the zip that contains the two vi's - one written for Linux and the other written for Windows.

[minnellac]

Eliot.ee, I don't know if this will be helpfull at all, but I can tell you that I am familiar with the symptoms you describe (at least running on XP). The description you provided regarding LabVIEW shutting down without an error or any other indication of a problem is exactly how LabVIEW responds on Windows when a required dll is not found. I'm not clear on how LabVIEW loads everything it needs, but it seems that if a dll which is called dynamically from within a dll that is called directly from a LabVIEW vi is unavailable, that is the behavior that I see. LabVIEW seems to check for the existence of "top-level" dll's when it loads a vi that calls something, but it doesn't check for the existence of everthing  that is required to run a given function. I've tried a few things to get around this: 1) add the path to all the libraries required to the system PATH variable, 2) change the working directory to the location of required libraries in LabVIEW after starting the program, but before calling any dll that needs them (this doesn't work if you can't even load your vi, obviously), 3) launch the vi from the directory containing the libraries (this seems to be related to the working directory as well).

anyway, good luck!
Chris

[elliot.ee]

Attached is a zip file that contains another interesting thing:

When I open up test_cvNamedWindow_LINUX.vi from post #5 within this message, it asks me to select libhighgui.so . I go to /usr/local/lib as seen in labview_startup.png. For whatever reason, when I double click on libhighgui.so (which is where the OpenCV function cvNamedWindow is located), the file dialog will keep on asking me to find libhighgui.so .

To make sure that I do have cvNamedWindow within libhighgui.so , I went to the folder that contained libhighgui.so and typed in the script nm -D which is the script that shows what functions are contained within libhighgui.so . nm-D.png shows the results which shows that cvNamedWindow is within the library.

How do you make sure that LabVIEW knows the path of the shared library? The path is within the environment variable PATH.

Any help or suggestion will be appreciated.

Thanks!

[elliot.ee]

Hey Chris,

I tried what you suggested and loaded all of the file paths into PATH. However, it did not work.
I also tried launching the vi from the library directory. It still did not work.

Your statement:

---

The description you provided regarding LabVIEW shutting down without an error or any other indication of a problem is exactly how LabVIEW responds on Windows when a required dll is not found. I'm not clear on how LabVIEW loads everything it needs, but it seems that if a dll which is called dynamically from within a dll that is called directly from a LabVIEW vi is unavailable, that is the behavior that I see. LabVIEW seems to check for the existence of "top-level" dll's when it loads a vi that calls something, but it doesn't check for the existence of everthing  that is required to run a given function.

---

makes sense. That explains why LabVIEW shuts down when I called edge.so since edge.so is a shared library file of edge.c whose main function calls certain OpenCV functions.

Thanks anyways for your suggestions!