[KDE/Mac] Repository for patches to fix KDE Problems on OS X

Ian Wadham iandw.au at gmail.com
Sun Jun 29 05:58:14 UTC 2014


On 29/06/2014, at 1:14 AM, Marko Käning wrote:
> In fact, if you want to build the debug variant for a single port I am
> afraid that EVERYTHING, down to qt4-mac will have to be built as debug
> variants, which means you'd have to build everything from scratch and
> cannot get prebuilt binaries from our buildbots.

Marko, I don't think Qt *has* to be built in debug mode when KDE is.  I certainly
do not do that in my non-MacPorts build environment.  In the following snippet,
#4 is a Qt no-debug trace (no detail): #5 and #6 are KDE debug traces (lots of detail).

#4  0x0000000110f7d72d in QObject::disconnect ()
#5  0x000000010f80cf58 in Palapeli::MovePieceInteractor::stopInteraction
      (this=0x7fb470d22680, event=@0x0) at
      /kdedev/kde4.13/kdesrc/kde/kdegames/palapeli/src/engine/interactors.cpp:140
#6  0x000000010f80c21a in Palapeli::Interactor::setInactive () at
      /kdedev/kde4.13/kdesrc/kde/kdegames/palapeli/src/engine/interactor.h:122

Full debug in Qt is verbose and not a lot of use.  If your app (or the KDE libs) go
there and crash, it is usually because they have already done something bad,
like running past the end of an array or list or pointing to a deleted object.

Is the globality of variants in MacPorts perhaps the reason why KDE and Qt
both have to be built in debug mode?

Cheers, Ian W.



More information about the kde-mac mailing list