kile-devel doesn't start

Michael Dickens michaelld at macports.org
Sun Nov 28 17:33:43 PST 2010


On Nov 28, 2010, at 7:16 PM, Ryan Schmidt wrote:
> On Nov 28, 2010, at 09:18, Thomas Schneider wrote:
>
>> objc[538]: Class QCocoaColorPanelDelegate is implemented in both /opt/local/lib/libQtGui.4.dylib and /Library/Frameworks/QtGui.framework/Versions/4/QtGui. One of the two will be used. Which one is undefined.
>
> Where did /Library/Frameworks/QtGui.framework come from? MacPorts doesn't put that there. Perhaps you put it there yourself. You should remove it. Stuff in /Library/Frameworks frequently interferes with stuff installed by MacPorts. Also carefully examine anything else in /Library/Frameworks and remove anything you don't absolutely need.

/Library/Frameworks/QtGui.framework is installed by Nokia's pre-compiled Qt download.

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?  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 -- if something from /Library/Frameworks comes up then the executable isn't being linked correctly.

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


More information about the macports-users mailing list