[CMake] CMake 2.8.3 built on OS X crashes on Startup.

Michael Jackson mike.jackson at bluequartz.net
Wed Jan 5 12:53:20 EST 2011 

Testing: You can launch the gui from the command line by passing the absolute path to the executable inside the app bundle:

509:[mjackson at ferb:CMake]$ /private/tmp/CMake-2.8.3/CMake\ 2.8-3.app/Contents/MacOS/CMake\ 2.8-3 
Qt internal error: qt_menu.nib could not be loaded. The .nib file should be placed in QtGui.framework/Versions/Current/Resources/  or in the resources directory of your application bundle.
Abort trap

And if there is a problem launching it you will get the above error message. I am sure there are some tricks to use to actually "ctrl-c" or kill it if there is NO error message. Of course if no-one is logged into OS X then you will probably get a different error message stating no access to the window server or something like that. 

--
Mike Jackson <www.bluequartz.net>

On Jan 5, 2011, at 12:34 PM, David Cole wrote:

> cmake-gui needs some further work to be automatically testable.
> 
> If we launched it as-is on a test run, then it would just hang there
> forever, waiting for user input as gui apps will do, and the test
> would timeout.
> 
> We'd need to add something like:
> - "--configure" "--generate" and  "--exit" command line switches that
> would do what they say
> - other scripting actions?
> - simulated gui interactions?
> 
> The reasons we haven't added a test yet:
> - It's a non-trivial test to add, which means it will take somebody a
> significant chunk of time
> - The pre-built Mac binary works fine: just download it and use it
> 
> A test would be good. If you have time, please add one and submit a
> patch. This particular test is simply not on the top of anybody's
> prioritized list right now.
> 
> We are relying on the community to try cmake-gui and ccmake during RC
> phases and tell us if something is amiss.
> 
> 
> Thanks,
> David
> 
> 
> On Wed, Jan 5, 2011 at 12:16 PM, Michael Jackson
> <mike.jackson at bluequartz.net> wrote:
>> Note that I am using the ./configure to configure CMake itself. Not CMake to configure CMake. So maybe there is something missing from those installs. The interesting part (with all the discussions with putting in bug reports) is that I even provided a patch for 2.8.0. Something got put into CVS (at the time) but not really sure what went in. So my conclusion is that there was a missing test to make sure that the built bundle actually launches which is why this was missed in all the automated testing.
>> ___________________________________________________________
>> Mike Jackson                      www.bluequartz.net
>> Principal Software Engineer       mike.jackson at bluequartz.net
>> BlueQuartz Software               Dayton, Ohio
>> 
>> On Jan 5, 2011, at 12:13 PM, David Cole wrote:
>> 
>>> This should have been fixed with the switch to using BundleUtilities
>>> for CMake's bundle.
>>> 
>>> The 2.8.3 BundleUtilities should copy in the Resources necessary for
>>> this to work.
>>> 
>>> So.... I think that was done (switch to using built in BU) just *after* 2.8.3.
>>> 
>>> 
>>> Unless there's still a missing qt.conf file at that point.
>>> 
>>> 
>>> On Wed, Jan 5, 2011 at 12:06 PM, Michael Jackson
>>> <mike.jackson at bluequartz.net> wrote:
>>>> Try the download from the CMake website, source download that is. Then configure and build and then install it.
>>>> 
>>>> ___________________________________________________________
>>>> Mike Jackson                      www.bluequartz.net
>>>> Principal Software Engineer       mike.jackson at bluequartz.net
>>>> BlueQuartz Software               Dayton, Ohio
>>>> 
>>>> On Jan 5, 2011, at 12:01 PM, Clinton Stimpson wrote:
>>>> 
>>>>> 
>>>>> I can't reproduce the problem using the current cmake source from git.
>>>>> 
>>>>> Clint
>>>>> 
>>>>> On Wednesday, January 05, 2011 08:05:43 am Michael Jackson wrote:
>>>>>> Reopened the bug because this is _still_ an issue with CMake 2.8.3. Just
>>>>>> tried to configure, build and install and got the same crash.
>>>>>> ___________________________________________________________
>>>>>> Mike Jackson                      www.bluequartz.net
>>>>>> Principal Software Engineer       mike.jackson at bluequartz.net
>>>>>> BlueQuartz Software               Dayton, Ohio
>>>>>> 
>>>>>> On Dec 5, 2009, at 5:05 PM, Mike Jackson wrote:
>>>>>>> Reported as bug number 10000 <http://paraview.org/Bug/view.php?id=10000>
>>>>>>> 
>>>>>>> Hey, do I get some sort of Cookie or something for having bug number
>>>>>>> 10,000? At least it will be easy to remember the bug number.
>>>>>>> 
>>>>>>> _________________________________________________________
>>>>>>> Mike Jackson                  mike.jackson at bluequartz.net
>>>>>>> 
>>>>>>> On Sat, Dec 5, 2009 at 4:59 PM, Mike Jackson
>>>>>>> 
>>>>>>> <mike.jackson at bluequartz.net> wrote:
>>>>>>>> Sorry No Patch but here is what needs to be inserted into
>>>>>>>> $CMAKE_SOURCE/Source/QtDialog/CMakeLists.txt.
>>>>>>>> 
>>>>>>>> I'll put some context around it for David or Bill to more easily find the
>>>>> place:
>>>>>>>> IF(APPLE)
>>>>>>>> 
>>>>>>>>   SET(CMAKE_POSTFLIGHT_SCRIPT
>>>>>>>> 
>>>>>>>>     "${CMake_BINARY_DIR}/Source/QtDialog/postflight.sh")
>>>>>>>> 
>>>>>>>>   SET(CMAKE_POSTUPGRADE_SCRIPT
>>>>>>>> 
>>>>>>>>     "${CMake_BINARY_DIR}/Source/QtDialog/postupgrade.sh")
>>>>>>>> 
>>>>>>>>   configure_file("${CMake_SOURCE_DIR}/Source/QtDialog/postflight.sh.in"
>>>>>>>> 
>>>>>>>>     "${CMake_BINARY_DIR}/Source/QtDialog/postflight.sh")
>>>>>>>> 
>>>>>>>>   configure_file("${CMake_SOURCE_DIR}/Source/QtDialog/postupgrade.sh.in
>>>>>>>>   "
>>>>>>>> 
>>>>>>>>     "${CMake_BINARY_DIR}/Source/QtDialog/postupgrade.sh")
>>>>>>>> 
>>>>>>>>   INSTALL(CODE "execute_process(COMMAND ln -s
>>>>>>>> 
>>>>>>>> \"../MacOS/${CMAKE_BUNDLE_NAME}\" cmake-gui
>>>>>>>> 
>>>>>>>>                 WORKING_DIRECTORY
>>>>>>>> 
>>>>>>>> \$ENV{DESTDIR}\${CMAKE_INSTALL_PREFIX}/bin)")
>>>>>>>> 
>>>>>>>>   INSTALL(CODE "set(input_file
>>>>>>>> 
>>>>>>>>      \"\$ENV{DESTDIR}\${CMAKE_INSTALL_PREFIX}/MacOS/${CMAKE_BUNDLE_NAME
>>>>>>>>      }\")")
>>>>>>>> 
>>>>>>>>   INSTALL(SCRIPT
>>>>>>>> 
>>>>>>>> "${CMake_SOURCE_DIR}/Source/QtDialog/CMakeIngestOSXBundleLibraries.cmake
>>>>>>>> ")
>>>>>>>> 
>>>>>>>>   IF (QT_MAC_USE_COCOA)
>>>>>>>> 
>>>>>>>>       INSTALL(CODE "execute_process(COMMAND /usr/bin/touch
>>>>>>>> 
>>>>>>>> \"../Resources/qt.conf\"
>>>>>>>> 
>>>>>>>>                        WORKING_DIRECTORY
>>>>>>>> 
>>>>>>>> \$ENV{DESTDIR}\${CMAKE_INSTALL_PREFIX}/bin)")
>>>>>>>> 
>>>>>>>>       INSTALL(CODE "execute_process(COMMAND cp -R
>>>>>>>> 
>>>>>>>> \"${QT_LIBRARY_DIR}/QtGui.framework/Resources/qt_menu.nib\"
>>>>>>>> \"../Resources/\"
>>>>>>>> 
>>>>>>>>        WORKING_DIRECTORY \$ENV{DESTDIR}\${CMAKE_INSTALL_PREFIX}/bin)")
>>>>>>>> 
>>>>>>>>   ENDIF(QT_MAC_USE_COCOA)
>>>>>>>> 
>>>>>>>> ENDIF(APPLE)
>>>>>>>> 
>>>>>>>> Hopefully that will get committed into CVS HEAD  asap as this probably
>>>>>>>> is getting pretty important with Snow Leopard defaulting to 64 bit
>>>>>>>> compiles, which forces Qt to be 64 bit, which forces Cocoa to be used,
>>>>>>>> which forces this patch..
>>>>>>>> 
>>>>>>>> Thanks
>>>>>>>> _________________________________________________________
>>>>>>>> Mike Jackson                  mike.jackson at bluequartz.net
>>>>>>>> 
>>>>>>>> On Sat, Dec 5, 2009 at 11:12 AM, Clinton Stimpson <clinton at elemtech.com>
>>>>> wrote:
>>>>>>>>>> It would be nice to have a function allowing one to override/extend
>>>>>>>>>> the default choice (which AFAIK is determined by asking otool about
>>>>>>>>>> link-dependencies). Perhaps something like this:
>>>>>>>>>> 
>>>>>>>>>> set_external_framework_properties(
>>>>>>>>>> 
>>>>>>>>>> ${QT_QTGUI_LIBRARY} PROPERTIES
>>>>>>>>>> REQUIRE Resources/qt_menu.nib DESTINATION <APP_BUNDLE>/Resources
>>>>>>>>>> REQUIRE Versions/Current/Headers DESTINATION <FRAMEWORK>
>>>>>>>>>> )
>>>>>>>>>> 
>>>>>>>>>> which sets a few directory properties which then are used by
>>>>>>>>>> fixup_bundle_item from the BundleUtilities for customizing the copied
>>>>>>>>>> framework. The <APP_BUNDLE> and <FRAMEWORK> strings could resolve to
>>>>>>>>>> the application-bundle being fixed up and the framework bundle
>>>>>>>>>> directory, respectively.
>>>>>>>>> 
>>>>>>>>> I'd prefer a default behavior that would work most of the time.
>>>>>>>>> I realize people can stuff whatever they want into a Framework, but
>>>>>>>>> some things are standard, and Resources is one of the standard ones,
>>>>>>>>> so I think that one should be fixed without having to make any changes
>>>>>>>>> to a user's CMakeLists.txt file.
>>>>>>>>> 
>>>>>>>>> Also, some frameworks that BundleUtilities would copy aren't
>>>>>>>>> necessarily known by cmake during link time, nor specified in any
>>>>>>>>> CMakeLists.txt file.
>>>>>>>>> 
>>>>>>>>> Clint
>>>>>> 
>>>>>> _______________________________________________
>>>>>> Powered by www.kitware.com
>>>>>> 
>>>>>> Visit other Kitware open-source projects at
>>>>>> http://www.kitware.com/opensource/opensource.html
>>>>>> 
>>>>>> Please keep messages on-topic and check the CMake FAQ at:
>>>>>> http://www.cmake.org/Wiki/CMake_FAQ
>>>>>> 
>>>>>> Follow this link to subscribe/unsubscribe:
>>>>>> http://www.cmake.org/mailman/listinfo/cmake
>>>> 
>>>> _______________________________________________
>>>> Powered by www.kitware.com
>>>> 
>>>> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>>>> 
>>>> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ
>>>> 
>>>> Follow this link to subscribe/unsubscribe:
>>>> http://www.cmake.org/mailman/listinfo/cmake
>>>> 
>> 
>> _______________________________________________
>> Powered by www.kitware.com
>> 
>> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>> 
>> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ
>> 
>> Follow this link to subscribe/unsubscribe:
>> http://www.cmake.org/mailman/listinfo/cmake
>>

More information about the CMake mailing list