MantisBT - CMake
View Issue Details
0015214CMakeCMakepublic2014-10-22 04:492015-06-01 08:38
Gregor Jasny 
Brad King 
normalmajoralways
closedfixed 
 
CMake 3.1CMake 3.1 
0015214: Error getting iOS compiler identification on master
Hello,

If I use cmake to compile the attached example for iOS it fails to get the compiler identification:

Compiling the C compiler identification source file "CMakeCCompilerId.c" failed.
Compiler:
Build flags:
Id flags:

The output was:
65
=== BUILD TARGET CompilerIdC OF PROJECT CompilerIdC WITH THE DEFAULT CONFIGURATION (Debug) ===

Check dependencies
target specifies product type 'com.apple.product-type.tool', but there's no such product type for the 
'iphoneos' platform

** BUILD FAILED **


I bisected the master branch and the offending commit is:

0cce556b5fbe629dccee294aeece7c275343ed64 is the first bad commit
commit 0cce556b5fbe629dccee294aeece7c275343ed64
Author: Brad King <brad.king@kitware.com>
Date:   Tue Apr 29 09:21:00 2014 -0400

    Xcode: Use sysroot and deployment target to identify compiler

    Use CMAKE_OSX_SYSROOT and CMAKE_OSX_DEPLOYMENT_TARGET to set the Xcode
    SDKROOT and MACOSX_DEPLOYMENT_TARGET build settings.  This is necessary
    because some versions of Xcode select a different compiler based on
    these settings.  We need to make sure the compiler identified during
    language initialization matches what will be used for the actual build.


The attached exmaple work with CMake 3.0.x but not with master. But maybe my toolchain file is incomplete?

Thanks,
Gregor
unpack the attached tarball, create a build directory and run:

~/src/cmake/bin/cmake -GXcode  -DCMAKE_TOOLCHAIN_FILE=../iOS.toolchain.cmake ..
-- The C compiler identification is unknown
-- The CXX compiler identification is unknown
CMake Error in :
  No CMAKE_C_COMPILER could be found.



CMake Error in :
  No CMAKE_CXX_COMPILER could be found.



-- Configuring incomplete, errors occurred!
Xcode 6.1 on OSX 10.10 (but fails with Xcode 5.1.1, too)
No tags attached.
related to 0015237closed Brad King No CMAKE_C_COMPILER could be found (3.1.0-rc1 regression) 
related to 0015329closed  try_compile fails for iOS targets 
gz cmakebug.tar.gz (737) 2014-10-22 04:49
https://public.kitware.com/Bug/file/5281/cmakebug.tar.gz
patch 0001-Retrieve-Xcode-CompilerId-via-static-libraries.patch (2,259) 2015-01-11 14:29
https://public.kitware.com/Bug/file/5340/0001-Retrieve-Xcode-CompilerId-via-static-libraries.patch
Issue History
2014-10-22 04:49Gregor JasnyNew Issue
2014-10-22 04:49Gregor JasnyFile Added: cmakebug.tar.gz
2014-10-22 09:01Brad KingNote Added: 0037064
2014-10-22 10:23Brad KingNote Added: 0037065
2014-10-22 10:23Brad KingAssigned To => Brad King
2014-10-22 10:23Brad KingStatusnew => assigned
2014-10-22 10:23Brad KingTarget Version => CMake 3.1
2014-10-23 08:34Brad KingStatusassigned => resolved
2014-10-23 08:34Brad KingResolutionopen => fixed
2014-10-23 08:34Brad KingFixed in Version => CMake 3.1
2014-11-07 15:56Brad KingRelationship addedrelated to 0015237
2014-12-19 07:59Gregor JasnyNote Added: 0037496
2014-12-19 08:41Brad KingNote Added: 0037499
2015-01-11 14:28Gregor JasnyNote Added: 0037664
2015-01-11 14:29Gregor JasnyFile Added: 0001-Retrieve-Xcode-CompilerId-via-static-libraries.patch
2015-01-11 15:45Brad KingRelationship addedrelated to 0015329
2015-01-11 15:50Brad KingNote Added: 0037668
2015-01-11 16:52Brad KingNote Added: 0037669
2015-06-01 08:38Robert MaynardNote Added: 0038834
2015-06-01 08:38Robert MaynardStatusresolved => closed

Notes
(0037064)
Brad King   
2014-10-22 09:01   
Prior to commit 0cce556b the compiler detection used an Xcode project for the host instead of the target so while the detection appeared to work it actually may have detected the wrong compiler. Related discussion that led to the change is here:

 CMake identifies MacOSX10.7-Xcode43-ub as GNU, but it runs clang.
 http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10033/focus=10043 [^]

I can reproduce this and get the error message you report:

 target specifies product type 'com.apple.product-type.tool', but there's no such product type for the 'iphoneos' platform

in CMakeFiles/CMakeError.log. It looks like our Xcode test project needs to use a different product type, at least for iOS.
(0037065)
Brad King   
2014-10-22 10:23   
The 'com.apple.product-type.bundle.unit-test' product type is available both in Xcode 5 and 6 and in both iPhoneOS and iPhoneSimulator. We can use that:

 Xcode: Fix compiler id detection for iOS tools
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c48f6e12 [^]

 Xcode: Fix compiler id detection when code signing is required
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b91020f6 [^]
(0037496)
Gregor Jasny   
2014-12-19 07:59   
With the current solution if you build for the device itself you always need a signing key, otherwise building the xctest bundle will fail (Xcode 6.1.1; iOS SDK 8.1).
Given the fact that you cross compile anyway and look at the embedded strings of the output why don't you simply build a static library and look into the generated object file?
(0037499)
Brad King   
2014-12-19 08:41   
Re 0015214:0037496: The iOS platform in Xcode does not allow a static library type.

I would certainly prefer to be able to avoid requiring a signing key but I do not know of any way to do it. Xcode simply requires one when linking anything for iOS devices.

Even if we got the compiler id working without a signing key, every try_compile would still need one, including the compiler ABI detection and test for working compiler.
(0037664)
Gregor Jasny   
2015-01-11 14:28   
I posted a patch to the mailinglist.
(0037668)
Brad King   
2015-01-11 15:50   
Re 0015214:0037664: For reference, the thread is:

 [PATCH] Retrieve Xcode CompilerId via static libraries
 http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/12072 [^]
(0037669)
Brad King   
2015-01-11 16:52   
Another approach is to drop signing altogether as proposed in 0015329:

 Xcode: Do not require code signing for compiler id
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7b7209f6 [^]
(0038834)
Robert Maynard   
2015-06-01 08:38   
Closing resolved issues that have not been updated in more than 4 months.