[PyKDE] Double definition of qApp in PyQt libraries?
ulrich.berning at t-online.de
Tue Nov 1 09:58:33 GMT 2005
Niels Vanspauwen schrieb:
> 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&,
> 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&,
> 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.
More information about the PyQt