kile-devel doesn't start

[Thomas Schneider]

On 29.11.2010, at 01:16, Ryan Schmidt wrote:

> Where did /Library/Frameworks/QtGui.framework come from? MacPorts doesn't put that there. Perhaps you put it there yourself.

Nope. I tried to install Kile from different sources (Fink, source archive) before, with different errors along the way. One of these approaches also required installing the latest version of Qt via Nokia as mentioned by Michael. I definitely didn't fiddle with the Library myself.

> You should remove it. Stuff in /Library/Frameworks frequently interferes with stuff installed by MacPorts.

OK, but: when I move /QtGui to another place, the kile script complains:

dyld: Library not loaded: QtGui.framework/Versions/4/QtGui
  Referenced from: /Library/Frameworks/phonon.framework/Versions/4/phonon
  Reason: image not found
Trace/BPT trap

When I move it back, all the previous messages and the crash are back.

> Also carefully examine anything else in /Library/Frameworks and remove anything you don't absolutely need.

How do I tell which of the 32 entries (of which 20 start with Qt) I "absolutely need"?

On 29.11.2010, at 02:33, Michael Dickens wrote:

> Why it is being found is another question -- it shouldn't be found or used (I think) unless it is in DYLD_LIBRARY_PATH which is set for the current shell environment.  Is DYLD_LIBRARY_PATH set in your shell environment when executing kile?  

Nope.

> If so, can you 'unset' it & try again?  Another helpful point would be to do 'otool -L' on the kile executable to see what libraries are supposed to be loaded & verify that they are all default Apple system and MacPorts --

$ otool -L kile.app/Contents/MacOS/kile
kile.app/Contents/MacOS/kile:
        /opt/local/lib/libkhtml.5.dylib (compatibility version 5.0.0, current version 5.5.0)
        /opt/local/lib/libkrosscore.4.dylib (compatibility version 4.0.0, current version 4.5.0)
        /opt/local/lib/libkfile.4.dylib (compatibility version 4.0.0, current version 4.5.0)
        /opt/local/lib/libktexteditor.4.dylib (compatibility version 4.0.0, current version 4.5.0)
        /opt/local/lib/libkparts.4.dylib (compatibility version 4.0.0, current version 4.5.0)
        /opt/local/lib/libkjs.4.dylib (compatibility version 4.0.0, current version 4.5.0)
        /opt/local/lib/libQtScript.4.dylib (compatibility version 4.7.0, current version 4.7.1)
        /opt/local/lib/libkio.5.dylib (compatibility version 5.0.0, current version 5.5.0)
        /opt/local/lib/libQtXml.4.dylib (compatibility version 4.7.0, current version 4.7.1)
        /opt/local/lib/libnepomuk.4.dylib (compatibility version 4.0.0, current version 4.5.0)
        /opt/local/lib/libsoprano.4.dylib (compatibility version 4.0.0, current version 4.3.0)
        /opt/local/lib/libQtNetwork.4.dylib (compatibility version 4.7.0, current version 4.7.1)
        /opt/local/lib/libkdeui.5.dylib (compatibility version 5.0.0, current version 5.5.0)
        /opt/local/lib/libQtSvg.4.dylib (compatibility version 4.7.0, current version 4.7.1)
        /opt/local/lib/libkdecore.5.dylib (compatibility version 5.0.0, current version 5.5.0)
        /opt/local/lib/libQtCore.4.dylib (compatibility version 4.7.0, current version 4.7.1)
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 123.0.0)
        /opt/local/lib/libQtDBus.4.dylib (compatibility version 4.7.0, current version 4.7.1)
        /System/Library/Frameworks/Carbon.framework/Versions/A/Carbon (compatibility version 2.0.0, current version 152.0.0)
        /opt/local/lib/libQtGui.4.dylib (compatibility version 4.7.0, current version 4.7.1)
        /opt/local/lib/libsolid.4.dylib (compatibility version 4.0.0, current version 4.5.0)
        /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.9.0)

> if something from /Library/Frameworks comes up then the executable isn't being linked correctly.

So would I have to tend to /System/Library/Frameworks/Carbon.framework then?

> I have worked on a number of tickets recently where this version of Qt was installed & was causing issues.  I've fixed the CMake Qt4 finding script to just look to where QTDIR is specified; the same script provided by KDE already limited the search path in this way.  Of course, all of these limited won't stop the user from messing with DYLD loading paths. - MLD

In this case, the user hasn't messed -- he has just tried to install kile as out-of-the-box as possible.

Cheers

Thomas