kile-devel doesn't start

Ryan Schmidt ryandesign at macports.org
Sun Nov 28 17:40:19 PST 2010


On Nov 28, 2010, at 19:33, Michael Dickens wrote:

> 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

See also

https://trac.macports.org/ticket/27094

https://trac.macports.org/ticket/25507



More information about the macports-users mailing list