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