| Anonymous | Login | Signup for a new account | 2010-09-02 13:22 EDT |
| Main | My View | View Issues | Change Log | Roadmap | Docs |
| Viewing Issue Simple Details [ Jump to Notes ] | [ View Advanced ] [ Issue History ] [ Print ] | ||||||||
| ID | Category | Severity | Reproducibility | Date Submitted | Last Update | ||||
| 0007011 | [CMake] CMake | major | always | 2008-05-13 17:44 | 2008-05-23 15:53 | ||||
| Reporter | Geoff Hutchison | View Status | public | ||||||
| Assigned To | Bill Hoffman | ||||||||
| Priority | normal | Resolution | fixed | ||||||
| Status | closed | Product Version | CMake-2-6 | ||||||
| Summary | 0007011: CMake hangs after "-- Found Qt-Version 4.3.4" on Mac OS X 10.5.2 | ||||||||
| Description |
I am currently trying to update to Qt-4.4 and CMake 2.6 on my Mac. Some friends have had luck, but every Mac I've tested, everything hangs after Qt-4.x is found (both for 4.3.4 and 4.4). I've tried running with cmake --debug-output, but nothing useful comes up. I'd be happy to help debug this (or find the bug myself), but cannot. CMake 2.4.x all worked cleanly on these Macs. |
||||||||
| Additional Information |
lsof shows: cmake 742 ghutchis cwd DIR 14,2 952 5120970 /Users/ghutchis/Devel/avogadro cmake 742 ghutchis txt REG 14,2 6562240 5558154 /Applications/CMake 2.6-0.app/Contents/bin/cmake cmake 742 ghutchis txt REG 14,2 1059776 4706834 /usr/lib/dyld cmake 742 ghutchis txt REG 14,2 135778304 5496740 /private/var/db/dyld/dyld_shared_cache_i386 cmake 742 ghutchis 0u CHR 16,0 0t29128 96934148 /dev/ttys000 cmake 742 ghutchis 1u CHR 16,0 0t29128 96934148 /dev/ttys000 cmake 742 ghutchis 2u CHR 16,0 0t29128 96934148 /dev/ttys000 |
||||||||
| Tags | No tags attached. | ||||||||
| Attached Files |
 Modules_FindOpenSSL_cmake.patch [^] (698 bytes) 2008-05-14 03:58 cmake-bt.txt [^] (4,001 bytes) 2008-05-16 17:33 |
||||||||
|
|
|||||||||
 Relationships [ Relation Graph ]
[ Dependency Graph ]
|
|
|
Notes |
|
|
(0011883) Clinton Stimpson (developer) 2008-05-13 23:45 |
Can you reproduce it with a minimal CMakeLists.txt file? ==== CMakeLists.txt ==== find_package(Qt4) ========================= |
|
(0011886) Michael Wild (reporter) 2008-05-14 03:28 |
CMake doesn't hang, and it isn't a problem of FindQt4.cmake neither. The problem lies in FindOpenSSL.cmake which gets called by FindQt4.cmake and is due to FIND_PATH(OPENSSL_INCLUDE_DIR openssl/ssl.h ) taking a very long time to complete. It seems as if FIND_PATH had serious problems with the partial path openssl/ssl.h. Using FIND_PATH(OPENSSL_INCLUDE_DIR ssl.h PATH_SUFFIXES openssl) seems to resolve the issue. |
|
(0011889) Michael Wild (reporter) 2008-05-14 04:07 edited on: 2008-05-14 04:08 |
The attached patch solves the issue with FindOpenSSL.cmake. However, I'm not sure whether this actually should be considered as a bug of FIND_PACKAGE. Timings: w/o patch: FindOpenSSL: 40-50s FindQt4: 50-60s with patch: FindOpenSSL: 1-2s FindQt4: 7-10s These measurements fluctuated quite heavily because I had some pretty demanding stuff running at the same time. |
|
(0011892) Geoff Hutchison (reporter) 2008-05-14 08:57 |
This does seem to resolve the issue for me. Thanks very much! |
|
(0011894) Geoff Hutchison (reporter) 2008-05-14 09:00 |
Ah, for future reference, yes the issue could be reproduced by a minimal CMakeLists.txt, and I never had FindQt4 complete -- even after 10s of minutes, although I also have millions of files. |
|
(0011912) Bill Hoffman (manager) 2008-05-14 15:16 |
That should work. Is it perhaps hitting a network path or something? Can you run ktrace or add some debug print into cmake, so we can figure out what is taking so long? There are lots of other modules that use find path like that so, this fix is really just a hack around a specific instance of the problem. |
|
(0011913) Bill Hoffman (manager) 2008-05-14 15:18 |
My guess is this: std::string cmFindPathCommand::FindHeaderInFramework(std::string& file, std::string& dir) { cmStdString fileName = file; cmStdString frameWorkName; cmStdString::size_type pos = fileName.find("/"); // if there is a / in the name try to find the header as a framework // For example bar/foo.h would look for: // bar.framework/Headers/foo.h if(pos != fileName.npos) { |
|
(0011918) Clinton Stimpson (developer) 2008-05-14 15:50 |
I'm not able to reproduce the slowness, or any speed up with the patch. For someone who can reproduce it, can you attach a ktrace of cmake? Perhaps the best way would be to do one cmake run on the minimal CMakeLists.txt, remove the OPENSSL_INCLUDE_DIR from the CMakeCache.txt, and do another run with "ktrace cmake ." and attach the ktrace.out file. The ktrace.out file will also include timings that we can look at. |
|
(0011923) Geoff Hutchison (reporter) 2008-05-14 17:36 |
Unfortunately, I'm using 10.5.x, so there's no ktrace. I haven't found anything on Google about emulating ktrace with dtrace. I also tried using the latter and Instruments to see what's going on. I took the advice of bill.hoffman and looked at the source. I modified cmdFindPathCommand::FindHeaderInFramework to add an std::cerr. I'm now in the process of attempting to bootstrap the source and hit the same hang. It looks like bootstrap has created an initial cmake: loading initial cache file /Users/ghutchis/Devel/tools/cmake-2.6.0/Bootstrap.cmk/InitialCacheFlags.cmake -- The C compiler identification is GNU -- The CXX compiler identification is GNU -- Check for working C compiler: /usr/bin/cc -- Check for working C compiler: /usr/bin/cc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working CXX compiler: /usr/bin/g++ -- Check for working CXX compiler: /usr/bin/g++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done At this point, I hit all of my new debugging statements: Find Header in Framework README.INSTALL /Users/ghutchis/Library/Frameworks/ Find Header in Framework README.INSTALL /Library/Frameworks/ Find Header in Framework README.INSTALL /Network/Library/Frameworks/ Find Header in Framework README.INSTALL /System/Library/Frameworks/ Find Header in Framework README.INSTALL /Users/ghutchis/Applications/ Find Header in Framework README.INSTALL /Applications/ Find Header in Framework README.INSTALL /Developer/Applications/ Find Header in Framework README.INSTALL /usr/local/bin/ Find Header in Framework README.INSTALL /opt/local/ Find Header in Framework README.INSTALL /opt/local/ Find Header in Framework README.INSTALL /usr/texbin/ Find Header in Framework README.INSTALL /usr/bin/ Find Header in Framework README.INSTALL /bin/ Find Header in Framework README.INSTALL /usr/sbin/ Find Header in Framework README.INSTALL /sbin/ Find Header in Framework README.INSTALL /usr/local/bin/ Find Header in Framework README.INSTALL /usr/X11/bin/ Find Header in Framework README.INSTALL /include/ Find Header in Framework README.INSTALL / (hang) That is, right now, it's looking for README.INSTALL in /. More debugging output indicates that the hang occurs in the globIt.FindFiles() call. Trying from the command-line, it seems like I'm hitting a hang with the /net directory. |
|
(0011938) Geoff Hutchison (reporter) 2008-05-14 19:36 |
If I change the FindHeaderInFramework function: std::string cmFindPathCommand::FindHeaderInFramework(std::string& file, std::string& dir) { if (dir == "/") return ""; cmStdString fileName = file; cmStdString frameWorkName; Everything appears to function normally. To me, this seems like an acceptable work-around, since headers will not be found in /*/Headers -- I can only find /Developer/Headers based off of that glob. (I believe this path is already searched.) |
|
(0011949) Bill Hoffman (manager) 2008-05-15 14:51 |
Odd thing that it is even looking in /. I wonder where that is coming from? Any ideas? |
|
(0011980) Geoff Hutchison (reporter) 2008-05-16 17:31 |
Since I know practically nothing about Cmake internals, I have no idea. Attached is a back-trace. The first hit is for cmFindPathCommand:FindHeaderInFramework() which is triggered when "/" is sent as the dir. Offhand, I'd guess "/" is set somewhere in a search path. |
|
(0012097) Bill Hoffman (manager) 2008-05-23 15:53 |
OK, this is fixed in CVS and should be in 2.6.1. I found out where the / was getting added into the search paths and removed it from there. Change to cmFindBase.cxx |
|
Issue History |
|||
| Date Modified | Username | Field | Change |
| 2008-05-13 17:44 | Geoff Hutchison | New Issue | |
| 2008-05-13 21:21 | Bill Hoffman | Status | new => assigned |
| 2008-05-13 21:21 | Bill Hoffman | Assigned To | => Clinton Stimpson |
| 2008-05-13 23:45 | Clinton Stimpson | Note Added: 0011883 | |
| 2008-05-14 03:28 | Michael Wild | Note Added: 0011886 | |
| 2008-05-14 03:53 | Michael Wild | Issue Monitored: Michael Wild | |
| 2008-05-14 03:58 | Michael Wild | File Added: Modules_FindOpenSSL_cmake.patch | |
| 2008-05-14 04:07 | Michael Wild | Note Added: 0011889 | |
| 2008-05-14 04:08 | Michael Wild | Note Edited: 0011889 | |
| 2008-05-14 08:57 | Geoff Hutchison | Note Added: 0011892 | |
| 2008-05-14 09:00 | Geoff Hutchison | Note Added: 0011894 | |
| 2008-05-14 15:14 | Bill Hoffman | Assigned To | Clinton Stimpson => Bill Hoffman |
| 2008-05-14 15:16 | Bill Hoffman | Note Added: 0011912 | |
| 2008-05-14 15:18 | Bill Hoffman | Note Added: 0011913 | |
| 2008-05-14 15:50 | Clinton Stimpson | Note Added: 0011918 | |
| 2008-05-14 17:36 | Geoff Hutchison | Note Added: 0011923 | |
| 2008-05-14 19:36 | Geoff Hutchison | Note Added: 0011938 | |
| 2008-05-15 14:51 | Bill Hoffman | Note Added: 0011949 | |
| 2008-05-16 17:31 | Geoff Hutchison | Note Added: 0011980 | |
| 2008-05-16 17:33 | Geoff Hutchison | File Added: cmake-bt.txt | |
| 2008-05-23 15:53 | Bill Hoffman | Status | assigned => closed |
| 2008-05-23 15:53 | Bill Hoffman | Note Added: 0012097 | |
| 2008-05-23 15:53 | Bill Hoffman | Resolution | open => fixed |
| 2008-06-23 13:19 | Adam Strzelecki | Issue Monitored: Adam Strzelecki | |
| Mantis 1.1.4[^] Copyright © 2000 - 2008 Mantis Group |  |
