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 _______________________________________________ macports-users mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
