[bug] Intermediate binaries compiled during cmake build are not signed when using ios.toolchain.cmake

[paidforby]

Describe the bug
Intermediate binaries compiled during the build step are not signed when using ios.toolchain.cmake. This prevents the binaries from being executed in later steps. Instead, their execution is immediately killed by OS. Below is an example of the error produced,

ios-cmake/example/simple-cmake/build-ioscmake/simple-cmake.build/Release-iphoneos/gcc_test.build/Script-301BF6151F823035A281835D.sh: line 12:  5131 Killed: 9               ./helloworld

To Reproduce
For demonstration purposes, I've created an exceedingly simple cmake example,

1. Clone my fork, https://github.com/paidforby/ios-cmake/tree/simple-cmake
2. cd ios-cmake/example/simple-cmake
3. mkdir build
4. cd build
5. cmake .. -G Xcode -DCMAKE_TOOLCHAIN_FILE=../../ios.toolchain.cmake -DPLATFORM=OS64
6. cmake --build . --config Release

Then the build should fail with the error I pasted above.

More interestingly, if you run the exact same cmake files, but without ios.toolchain.cmake. It builds with no issues, indicating that the toolchain is making some change that is triggering this bug. Obviously, my simple example doesn't actually depend on the toolchain, I have an actual use case for which I would like to use it that produces the same bug.

Expected behavior
Build a correctly signed helloworld binary that can be executed within the build process.

Environment
cmake version 3.24.4
Chip - Apple M2 Pro
macOS - Venture 13.4.1

My faulty CMakeLists.txt

FWIW, I've noticed that dmesg also shows a clearly related error that "ASP: Security policy would not allow process", see below for context,

[80650.330822]: Waking up reference: 1230Thread waiting on reference 1230 woke upevaluation result: 1230, allowed, cache,  1688833619arm64e_plugin_host: running binary "bash" in keys-off mode due to identity: com.apple.bashSandbox apply: mdworker_shared[6681] <bytes>arm64e_plugin_host: running binary "bash" in keys-off mode due to identity: com.apple.bashWaking up reference: 1231Thread waiting on reference 1231 woke upevaluation result: 1231, allowed, cache,  1688833619arm64e_plugin_host: running binary "bash" in keys-off mode due to identity: com.apple.basharm64e_plugin_host: running binary "bash" in keys-off mode due to identity: com.apple.bashWaking up reference: 1232Thread waiting on reference 1232 woke upevaluation result: 1232, allowed, cache,  1688833619arm64e_plugin_host: running binary "bash" in keys-off mode due to identity: com.apple.basharm64e_plugin_host: running binary "bash" in keys-off mode due to identity: com.apple.bashWaking up reference: 1233Thread waiting on reference 1233 woke upevaluation result: 1233, allowed, cache,  1688833619arm64e_plugin_host: running binary "bash" in keys-off mode due to identity: com.apple.bashAMFI: hook..execve() killing pid 6695: Attempt to execute completely unsigned code (must be at least ad-hoc signed).
[80650.558765]: Thread waiting on reference 1234 woke upASP: Sleep interrupted, signal 0x100
[80650.558768]: ASP: Security policy would not allow process: 6695, ....ios-cmake/example/simple-cmake/build/gcc_test/src/gcc_test/gcc/test_files/helloworld
[80650.567095]: PMRD: power event 14 args 0 0x0
[80650.595484]: ASP: Could not find reference 1234, process must have died

[paidforby]

Oh, I also neglected to mentioned that if I remove the -G Xcode flag, but keep the DCMAKE_TOOLCHAIN_FILE=../../ios.toolchain.cmake, it also builds fine. So perhaps it is triggered by some combination of the toolchain and the Xcode generator.

[leetal]

I've never put any effort into adding support for code signing. Using upstream codesigning flags provided by CMAKE "should" work. But it's up to the developer to provide the correct profiles and certificates.

[paidforby]

Thanks for considering this. I understand and agree, code-signing is a huge pain and only becoming more difficult with the new Apple chips.

I ended up learning that the real issue was that the intermediate binaries were being built with iOS as their target instead of MacOS, so obviously I wouldn't be able to execute them on a Mac. This left me in the lurch with cross-compiling for iOS, how can I build libraries that depend on compiling and running a binary for MacOS as a helper for completing the iOS build?

The solution I came up with was to "bootstrap" my iOS cross-compile from a native MacOS build of the same library. So first, I let cmake build the entire library for MacOS. Then, when running the iOS build, I provide cmake with the path to that MacOS build, from which it copies any binaries that must be executed during the build.

If you are exceedingly curious, you can see my relatively simple fix for building boost libraries. Instead of allowing bootstrap.sh to compile an unusable b2 binary, I just copy the binary from the MacOS build and use that to compile my iOS libraries.

I have no idea if this is the "right" way to solve this, but I tried many other solutions to force the intermediate binaries to compile for and execute on MacOS with no luck.