Usign libokFrontPanel.so from another shared object

Hello!
I encountered a problem using libokFrontPanel.so from another shared object. Application segfaults during execution of this line

okCUsbFrontPanel *device;
device= new okCUsbFrontPanel();

Actually this is the same problem which is described here
http://forums.opalkelly.com/showthread.php?886-using-libokFrontPanel.so-in-a-shared-library
, but as nobody did not answered on my question there I started new thread.
Can you tell me please how can I avoid segfault?
Thanks in advance.

What, specifically, is causing the segfault?

device  = new okCUsbFrontPanel(); //<<<<---- segmetation fault in this line.

analyzing code of okFrontPanel.h and okFrontFanel.cpp I found out that constructor of okCUsbFrontPanel class calls okFrontPanel_Construct function with _okFrontPanel_Contruct pointer. But magically constructor calls itself (it is visible from gdb backtrace). As result I have stack overflow and segfault. I suppose that resolved during okFrontPanel_LoadLib() call _okFrontPanel_Construct pointer points not on okFrontPanel_Construct function but on okCUsbFrontPanel constructor.

Please note that I call

ret = okFrontPanel_LoadLib()

before I call

new okCUsbFrontPanel()

and check result. It return 1 that means no errors.

Looking forward for your cooperation.

I doubt the constructor is calling itself. However, gdb might be showing you symbols that seem to indicate that.

DLLs (and shared objects) don’t work well with C++ classes. So the DLL is really a C API to the C++ object we have (okCUsbFrontPanel). Our stub file (okFrontPanel.cpp), however, provides a C++ convenience wrapper around the C API. This makes it look like the C++ object was used in the first place.

So we have:

okCUsbFrontPanel (our “real” C++ class encapsulating the API functionality)
.
C functions that expose the designer API functionality
.
DLL exposing the C functions
.
okFrontPanel.cpp with C-style stub functions accessing the DLL
.
okCUsbFrontPanel, a C++ wrapper around the C-style stub functions.

So this may be how you’re seeing that okCUsbFrontPanel is trying to call its own constructor. It’s really calling the constructor of the “real” C++ class that is inside the DLL.

Hi!
Now I understand what happens here. Thank you very much for your help. Solution for me is to change class names in header and cpp files supplied (okFrontPanel.h okFrontPanel.cpp) on something like okCUsbFrontPanelx, okCPLL23150x and okCPLL22150x and instead of

ptr = new okCUsbFrontPanel()

use

ptr = new okCUsbFrontPanelx();

This works for me.

Thank again for help! :slight_smile: