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.
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