MantisBT - CMake
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0013271CMakeCMakepublic2012-06-05 12:012016-06-10 14:31
Reporterrecryn 
Assigned ToKitware Robot 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionmoved 
PlatformAppleOSMac OS XOS Version10.6.8
Product VersionCMake 2.8.8 
Target VersionFixed in Version 
Summary0013271: is_file_executable() from GetPrerequisites.cmake erroneously returns 0 for universal binaries (MacOSX)
DescriptionOn UNIX is_file_executable() executes the tool 'file' and then compares the returned string with "executable": if("${file_ov}" MATCHES "executable")

However, on MacOSX, there are several 'file' tools available (macports, fink) which do not share the same output format. Most notably, the output string does not always match "executable" if the file is a universal binary. Here are some possible output strings of 'file' for three different executables on a Mac:
  Mach-O executable i386
  Mach-O 64-bit executable
  Mach-O fat file with 2 architectures

'file /bin/ls' results just in:
/bin/ls: Mach-O fat file with 2 architectures

Note, that a library would be reported as: "Mach-O 64-bit dynamically linked shared library". So matching Mach-O is no good either.

Ideally is_file_executable() would call 'otool -hv' on APPLE and match the result with "EXECUTE", e.g.:

otool -hv /bin/ls
/bin/ls:
Mach header
      magic cputype cpusubtype caps filetype ncmds sizeofcmds flags
MH_MAGIC_64 X86_64 ALL LIB64 EXECUTE 13 1928 NOUNDEFS DYLDLINK TWOLEVEL
Steps To Reproduce1. Install 'file' from macports:
port install file

2. Prepend macports binary dir (/opt/local/bin) to PATH

3. With a project that uses fixup_bundle:
cmake -DCMAKE_OSX_ARCHITECTURES="x86_64;i386"
make
cpack -G Bundle --verbose

[...]
CPack Verbose: libs=''
CPack Verbose: dirs=''
CPack Verbose: warning: *NOT* handled - not .app dir, not executable file...
CMake Error at /opt/local/share/cmake-2.8/Modules/MyBundleUtilities.cmake:723 (message):
  error: fixup_bundle: not a valid bundle
Call Stack (most recent call first):
  /tmp/trunk/build/cmake/dist/cmake_install.cmake:38 (fixup_bundle)
  /tmp/trunk/build/cmake_install.cmake:36 (INCLUDE)
Additional InformationPatch attached.
TagsNo tags attached.
Relationships
related to 0013764closed Kitware Robot is_file_executable() from GetPrerequisites.cmake erroneously returns 0 for DLL on windows 
Attached Filesdiff GetPrerequisites.cmake.diff (2,091) 2012-06-05 12:01
https://public.kitware.com/Bug/file/4343/GetPrerequisites.cmake.diff
Issue History
Date ModifiedUsernameFieldChange
2012-06-05 12:01recrynNew Issue
2012-06-05 12:01recrynFile Added: GetPrerequisites.cmake.diff
2012-08-11 21:37David ColeAssigned To => David Cole
2012-08-11 21:37David ColeStatusnew => assigned
2012-11-21 14:57David ColeNote Added: 0031654
2012-11-21 14:59David ColeAssigned ToDavid Cole =>
2012-11-21 15:11David ColeStatusassigned => new
2012-11-21 15:11David ColeNote Added: 0031666
2012-11-30 14:33David ColeRelationship addedrelated to 0013764
2016-06-10 14:28Kitware RobotNote Added: 0042059
2016-06-10 14:28Kitware RobotStatusnew => resolved
2016-06-10 14:28Kitware RobotResolutionopen => moved
2016-06-10 14:28Kitware RobotAssigned To => Kitware Robot
2016-06-10 14:31Kitware RobotStatusresolved => closed

Notes
(0031654)
David Cole   
2012-11-21 14:57   
Un-assigning bugs that are not on the active roadmap, which no developers are actively working on for the CMake 2.8.11 release.

If one gets put back on the roadmap, re-assign it appropriately at that time.
(0031666)
David Cole   
2012-11-21 15:11   
Re-setting status back to "new" for bugs that are "assigned" but not assigned to a specific developer. When/if these bugs go back on the roadmap for a specific version, assignment to an appropriate developer should take place then...
(0042059)
Kitware Robot   
2016-06-10 14:28   
Resolving issue as `moved`.

This issue tracker is no longer used. Further discussion of this issue may take place in the current CMake Issues page linked in the banner at the top of this page.