[PySide] Distinguishing QEvents originating in PySide2 from those originating in C++

[Stephen Morris]

In Linux, the libraries libpyside2-python2.7.so.5.15, libshiboken2-python2.7.so.5.15 and shiboken2.so don't link directly with libpython2.7.so.1.0, according to 'ldd', but using the 'nm' utility reveals that they still depend on a lot of Python symbols exported by the Python library,

e.g. 'nm lib/python2.7/site-packages/PySide2/libpyside2-python2.7.so.5.15 | fgrep Py_'
                 U Py_BuildValue
                 U Py_FatalError
                 U Py_GetProgramFullPath
                 U Py_GetRecursionLimit
                 U Py_IsInitialized
                 U _Py_NoneStruct
                 U Py_SetRecursionLimit
                 U _Py_TrueStruct
                 U _Py_ZeroStruct

Presumably they depend upon libpython2.7.so.1.0 having been loaded into memory by another part of the application.

Faced with the unusual need to have both libpython2.6 and libpython2.7 in memory at the same time (I won't bore you with the details),  I do not link to libpython2.7.so.1.0 directly but I have wrapped it in 'Proxy interface', basically a .c file providing definitions for Py_BuildValue, Py_FatalError and so on that are dynamically loaded at runtime (using dlopen and dlvsym) to ensure that the correct pointers are obtained from libpython2.7 and never from libpython2.6. 

For my main application this works well, but it means that my "ProxyPython27.c" file needs to be compiled alongside my source code to make sure that the definitions are available at compile time. I suppose it would work if I made it a static library, but it won't work if I make it a dynamic library since once again the exported symbols would conflict with those from libpython2.6.so.1.0.

So, my question: in order to get my ProxyPython27.c file compiled and linked into libpyside2-python2.7.so.5.15, libshiboken2-python2.7.so.5.15 and shiboken2.so when I build them, where are the most efficient locations for me to modify in the configuration and build files?

Thank you,
Stephen Morris.