Your coworker is correct about the LTO object files being LLVM bitcode.

To link them reliably you need to use the exact same LLVM toolchain that created them.

Path of least resistance is to avoid LTO.

We can consider it for sure, it's just a lot more artifacts to build if we include PGO-only builds.

Is it feasible to build these yourself? Or do you need to target a bunch of platforms?

We are currently using the following builds:

• macOS
  • AArch64 (aarch64-apple-darwin, pgo-full)
  • x86-64 (x86_64-apple-darwin, pgo-full)
• Linux
  • AArch64 (aarch64-unknown-linux-gnu, noopt-full) (no PGO available)
  • x86-64 (x86_64_v2-unknown-linux-gnu, pgo-full)
• Non-PBS builds
  • iOS AArch64 using BeeWare's Python-Apple-support
  • Windows x86-64 from NuGet

We technically only need to embed the Python interpreter on iOS (due to only being allowed one process per app),
but for easier testing and consistency between builds we also do this on macOS and Linux.

My preference is to maintain as little as possible myself and to reduce deviation between our platforms. Assuming that PGO remains a valid build configuration, it would be possible for us to fork and build ourselves. I imagine this will be our fallback position (I don't love the idea of using the debug-full builds).

As an aside we use Conan to build our other C/C++ dependencies internally. We haven't explored using it for CPython, but that might also be a way forward for us (I can see a recipe does already exist with some patches)

We have dropped our use of embedded Python in macOS and Linux (and iOS), and so no longer need this.

As an aside, we did experiment with using Conan to build CPython. We found the recipe worked fine, but there do seem to be some quirks for macOS. After compiling with our initial attempt we were missing the standard library, but haven't looked into it further.

Will close the issue since I don't see anyone else asking for this variant. Should this change in the future I guess this issue could be reopened or a new issue created 👍