Open paidforby opened 1 year ago
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.
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.
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.
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,
To Reproduce For demonstration purposes, I've created an exceedingly simple cmake example,
cd ios-cmake/example/simple-cmake
mkdir build
cd build
cmake .. -G Xcode -DCMAKE_TOOLCHAIN_FILE=../../ios.toolchain.cmake -DPLATFORM=OS64
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,