On Sunday 16 October 2005 07:38, Mark Hymers wrote: > So it looks like some sort of KDE-3.4, Qt-3.3.5 interaction. It is > highly unlikely to be a g++ transition issue as that side is pretty much > finished in Debian now and I'm sure that kst's dependencies have been > transitioned as has kst.
I agree- I have rebuilt all of Xorg + Qt + KDE from source packages using the gcc 4.0.2 toolchain in unstable. The resulting packages exhibit the same problem. > Ted, you mentioned some sort of Qt-3.3.5 / KDE-3.4 interaction; > unfortunately I don't know much about this; can you point me in the > right direction? I had thought this might have been a problem. See this bug report: http://bugs.kde.org/112500 I'm not sure if KDE 3.4.2 included in debian unstable has been patched. However, I think the fact that we can compile kdelibs and kst means that this is not an issue (i.e, it dealt with ui files during compile time). The KDE website explicitly says to *NOT* use Qt 3.3.5 with KDE 3.4/3.5, but I don't know if this ui issues is the only reason... I'm assuming that the debian-kde people know what they are doing in choosing to use Qt 3.3.5 ;-) Hopefully any necessary patches have been applied... > I've compiled kst with debugging symbols and am now attempting to obtain > some useful backtraces; if anyone has any ideas I'd be happy to hear > them! I've tried this as well, along with using the xserver-xorg-dbg libraries. Unfortunately I'm not too familiar with debuggers, and kst actually doesn't "crash", it just generates X errors. How does one generate a backtrace without a crash point? It seems like we need to actually set breakpoints at various places and see which KDE/Qt/X function call is causing the error. I'll try to look at this more soon. -Ted -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
