MantisBT - CMake
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0012640CMakeCMakepublic2011-12-25 08:272016-06-10 14:31
ReporterDaniel Dekkers 
Assigned ToKitware Robot 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionmoved 
PlatformiOSOSMac OSOS Version
Product VersionCMake-2-8 
Target VersionFixed in Version 
Summary0012640: set(CMAKE_XCODE_EFFECTIVE_PLATFORMS "-iphoneos;-iphonesimulator") fails when archiving.
DescriptionWhen building and linking to a static library in your iOS project, CMAKE_XCODE_EFFECTIVE_PLATFORMS lets you declare the correct build paths to the library. Enabling you to change schemes between device and simulator on the fly in Xcode. But this doesn't work when archiving, the library is not found during the linking phase.
Steps To ReproduceThe iOSNavApp example in the CMake test suite shows this behavior.
Additional InformationI have another small example based on the standard XCode (4.0.2) OpenGL|ES application template available if needed: d.dekkers@cthrough.nl.

Also nice to know: Xcode 4.2 doesn't show details of the linking error. Xcode 4.0.2 does.
TagsNo tags attached.
Relationships
related to 0013048closed Kitware Robot CMake 2.8.7 Nightly fails to link correctly in XCode 4.3 
Attached Fileszip openglescmakewithlib.zip (22,925) 2011-12-25 08:50
https://public.kitware.com/Bug/file/4151/*
zip openglescmakewithlib_iOS5.1.zip (22,179) 2012-04-03 10:37
https://public.kitware.com/Bug/file/4281/openglescmakewithlib_iOS5.1.zip
Issue History
Date ModifiedUsernameFieldChange
2011-12-25 08:27Daniel DekkersNew Issue
2011-12-25 08:50Daniel DekkersFile Added: openglescmakewithlib.zip
2011-12-25 08:54Daniel DekkersNote Added: 0028073
2011-12-27 19:17David ColeAssigned To => David Cole
2011-12-27 19:17David ColeStatusnew => assigned
2012-01-07 09:59David ColeTarget Version => CMake 2.8.8
2012-04-03 10:34Daniel DekkersNote Added: 0029064
2012-04-03 10:37Daniel DekkersFile Added: openglescmakewithlib_iOS5.1.zip
2012-04-03 10:38Daniel DekkersNote Added: 0029065
2012-04-03 12:10David ColeRelationship addedrelated to 0013048
2012-04-19 08:50David ColeTarget VersionCMake 2.8.8 => CMake 2.8.9
2012-05-21 11:21Jonathan LilliemarckNote Added: 0029524
2012-07-09 07:13David ColeNote Added: 0029989
2012-07-09 07:20David ColeTarget VersionCMake 2.8.9 =>
2012-11-21 14:57David ColeNote Added: 0031658
2012-11-21 15:00David ColeAssigned ToDavid Cole =>
2012-11-21 15:11David ColeStatusassigned => new
2012-11-21 15:11David ColeNote Added: 0031664
2015-12-30 08:25Gregor JasnyNote Added: 0040030
2016-06-10 14:28Kitware RobotNote Added: 0041947
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
(0028073)
Daniel Dekkers   
2011-12-25 08:54   
The problem seems to be that when building for device or simulator the library is built in path/to/build/[config]-iphoneos or path/to/build/[config]-iphonesimulator. But when archiving, the library is built in XCode's derived data directory.
(0029064)
Daniel Dekkers   
2012-04-03 10:34   
Things seem to have improved with Xcode4.3/iOS5.1
The lib is now correctly built at the correct location, i.e. [cmakebuilddirectory]/[libname]/[configuration]-iphoneos (with configuration Debug, Release, ...).
You still have to edit the schemes to make sure a Release build of the lib is performed (it's not automatically triggered by invokating an archive build).
(0029065)
Daniel Dekkers   
2012-04-03 10:38   
openglescmakewithlib_iOS5.1.zip is a version of the small self contained example but now using the iOS 5.1 SDK.
(0029524)
Jonathan Lilliemarck   
2012-05-21 11:21   
openglescmakewithlib_iOS5.1.zip doesn't work for me. Maybe you clicked Build For -> Archiving which will put the library files in the expected places. After that it is possible to Archive the app.

I think the solution is to link libraries with a build phase just like Xcode would have done. If I manually do the following changes to project.pbxproj archiving will work.

Add this section (between PBXFileReference section and PBXGroup section)

/* Begin PBXFrameworksBuildPhase section */
        AB88FFCD156A7ABC00185B0D /* Frameworks */ = {
            isa = PBXFrameworksBuildPhase;
            buildActionMask = 2147483647;
            files = (
            );
            runOnlyForDeploymentPostprocessing = 0;
        };
/* End PBXFrameworksBuildPhase section */

Add a reference to the build phase to buildPhases

AB88FFCD156A7ABC00185B0D /* Frameworks */,

Remove liblib.a from from OTHER_LDFLAGS. Open the project in Xcode. Go to Build Phases and add liblib.a to the build phase "Link Binary With Libraries". (This makes a PBXBuildFile for liblib.a appear).
(0029989)
David Cole   
2012-07-09 07:13   
Unset target version field; too late for a fix to go into 2.8.9; deferred until a future version.
(0031658)
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.
(0031664)
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...
(0040030)
Gregor Jasny   
2015-12-30 08:25   
With CMake 3.4 (maybe already 3.3) CMAKE_XCODE_EFFECTIVE_PLATFORMS is gone and we detect iOS/watchOS/tvOS presence solely be the SDK name. CMake 3.5 will also support fused installs of device and simulator targets (see IOS_INSTALL_COMBINED target property).

Could you please check if the described error still happens?
(0041947)
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.