[MacPorts] #27186: lprof @20090113 Failure configuring with QTASSISTANT
MacPorts
noreply at macports.org
Wed Nov 17 15:40:43 PST 2010
#27186: lprof @20090113 Failure configuring with QTASSISTANT
-----------------------------------+----------------------------------------
Reporter: bernard@… | Owner: macports-tickets@…
Type: defect | Status: new
Priority: Normal | Milestone:
Component: ports | Version: 1.9.1
Keywords: lprof qt4 qtassistant | Port: lprof
-----------------------------------+----------------------------------------
Comment(by michaelld@…):
Thank you for the logfile; I'll look through it & see what I can make out.
I'm making progress on the CMake Qt4 file too, so I'm getting an idea of
what to change to make finding Qt4 work more robustly.
MacPorts installs Qt4 (via qt4-mac) into ${prefix}, which by default (and
in your and my cases) is "/opt/local". If you do "find /opt/local/lib
-name "*Qt*.dylib" -type f" you'll get back a laundry list of installed Qt
libraries. If you now look in /Library/Frameworks (e.g., "ls -ld
/Library/Frameworks/*Qt* /Library/Frameworks/*honon*") you'll see a
similar list, but in this case just top-level directories (frameworks)
instead of actual libraries. If you compare and contrast the lists, you
should find that they contain about the same members (e.g.,
libQtCore.X.dylib -> QtCore). Hence, you can safely do "sudo rm -rf
/Library/Frameworks/*Qt* /Library/Frameworks/*honon*" to get rid of that
(old?) install of Qt without impacting those installed by MacPorts.
Now, it is possible that you require that Qt install for something else,
in which case you don't want to delete it. Only you know the answer to
this question :)
--
Ticket URL: <https://trac.macports.org/ticket/27186#comment:36>
MacPorts <http://www.macports.org/>
Ports system for Mac OS
More information about the macports-tickets
mailing list