This one caught us by surprise. For some mysterious reason, the GCC run-time library intercepts a call between two QT system objects at a place where the application has received a system message, and is attempting to determine what kind of event it represents. The runtime library attempts to apply a "dynamic cast" function, and this fails, producing the fault.

It is not unexpected that requirements of the old QT system interface and the newer C++ runtime would diverge at some point. However, we don't know exactly where or when this happened. Since the fault occurs on a call between two binary pre-compiled libraries, with no accessible source code between, we don't have any obvious way to fix this.

The only available workaround is to switch the GCC compiler from the C++ mode (as shown in the original code examples) to the C mode. Prepare your application source code accordingly. Also, you must make the following patches to the DSCIO header file to replace some C++ "typed static constant" initializations with explicit constant values.

const int DscPin_S0 = DscPin_A0;   // C++ only
const int DscPin_S0 = 0x00000001;     // See DscPin_A0 definition above

There is a short sequence of these initializations, and modify them all similarly.

Also, there is a definition of a reserved buffer area that uses a "static typed constant" for the array length. This must also be recoded using an explicit numerical dimension.

char achName[cFilterNameLength + 1];   // C++ only
char achName[64];       // length == (cFilterNameLength+1)

After these changes, the interface code should compile fine as "C" language code. For some reason, runtime library doesn't get involved and things can start to work normally.