[PyKDE] Double definition of qApp in PyQt libraries?

[Ulrich Berning]

Niels Vanspauwen schrieb:

> Hi,
>
>
> I'm trying out PyQt and have run into a weird problem which I can't 
> seem to resolve. I've searched the internet and the PyQt wiki for the 
> answer but alas. Therefore, I turn to you in the hope you can help me. 
> I'm running on RedHat8, using gcc 3.2.3, QT 3.3.5 (static 
> multithreaded), PyQt 3.15 and SIP 4.3.1.
>
> The problem is the following: following the instructions to the 
> letter, I can build the PyQt libraries without any problems. I can run 
> example applications without problems too, _except_ for any example 
> that uses QCanvas. For example, if I run examples3/canvas/canvas, I 
> get the following error message:
>
>    QPaintDevice: Must construct a QApplication before a QPaintDevice
>
> Looking at the QT source code, this is because the qApp pointer is 0. 
> Looking at the Python code of the example though, it's clear that the 
> QApplication constructor is called _before_ any constructor of a 
> QPaintDevice descendant, so something is very wrong.
>
> After some debugging, it appears to me that there are _two_ copies of 
> the qApp pointer in the program! One is defined in qt.so and the other 
> in qtcanvas.so. For example, if I do: "nm qt.so | grep qApp | c++filt" 
> I get:
>
> 00987b0c t _GLOBAL__D_qApp
> 00987af0 t _GLOBAL__I_qApp
> 00a52670 t qAppendItems(QTextEngine*, int&, int&, BidiControl&, 
> QChar::Direction)
> 004a6466 t func_qAppName(_object*, _object*)
> 004a6506 t func_qAppClass(_object*, _object*)
> 00927600 T qAppName()
> 0092760a T qAppClass()
> 00f5e638 D qApp
> 00f1d59c D sipNm_qt_qApp
> 00f1e0af D sipNm_qt_qAppClass
> 00f1e090 D sipNm_qt_qAppName
>
> The interesting part is the "D qApp", clearly indicating that qApp is 
> defined in the data section.
>
> Doing the same command on qtcanvas.so yields:
>
> 002a80ec t _GLOBAL__D_qApp
> 002a80d0 t _GLOBAL__I_qApp
> 0030f7d4 t qAppendItems(QTextEngine*, int&, int&, BidiControl&, 
> QChar::Direction)
> 0041077c T qAppName()
> 00410786 T qAppClass()
> 006d8a24 D qApp
>
> Notice the last line: qApp also appears to be defined here!
>
> Therefore I conclude that Qt's qapplication.o file must be included in 
> both qt.so and qtcanvas.so, which seems odd to me.
>
> What I _think_ happens when I run the examples3/canvas/canvas.py 
> application is the following:
> 1. qt.qApp get's initialized to 0 by importing the module qt and 
> loading the qt.so file
> 2. qtcanvas.qApp get's initialized to 0 by importing the module 
> qtcanvas and loading the qtcanvas.so file. I don't know how the loader 
> resolves the conflict of the double definition of qApp, but I'm 
> guessing it just creates two copies.
> 3. qt.qApp get's initialized by calling QApplication constructor
> 4. When the QCanvas is constructed, it refers to qtcanvas.qApp (since 
> that reference should have been resolved already when building the .so 
> file), which is still 0, so we get the error.
>
>
> So far for my research. Now my questions: given that I find so little 
> help on the web for this, I'm guessing that there's nothing wrong with 
> the way PyQt works, but there's something wrong with my setup or with 
> the way I built PyQt. I'm assuming that examples3/canvas/canvas works 
> fine on your system.
>
> Do you have any idea what I could be doing wrong?
>
You can't build SIP/PyQt as dynamic loadable modules linked with a 
static Qt library. You either have to link SIP/PyQt with a shared Qt 
library or you have to build SIP/PyQt as static libraries and link 
everything into a single Python interpreter.

Ulli