"Build Built On: SnowLeopard 10A411"
for which, he writes:
"the C++ runtime had been changed for the x86_64 platform. This involved relocation several symbols to another part of the kernel. Unfortunately, the way this was implemented in the header was #if __i386__ || __ppc__" referring to issues for initial cross-compilation from what I understand.
Could this mean that cross-compilation to ppc became unsupported as of 10A411 only?
I doubt it. Owing to what we are beginning to understand was probably a diligent effort internally to have contingencies ready, it appears more likely that Apple, at least through the 10A432 “Golden Master”, maintained some kind of multi-architecture production stream which, at a minimum, also included a UB version with support for PowerPC Macs. I have no idea whether Apple also devoted human resources to maintaining a skeleton build for ARM, but I suppose if they wanted to, they would have had the knowledge and resources to probably do so.
I suspect, however, that even a UB fork, all the way to 10A432, probably came up short for functional components like hardware graphics support for AGP video cards on pre-PCIe G5s in the PowerPC line of Macs, and OpenCL support on non-Intel architecture was probably fairly limited. I mean, it’s entirely possible they turned to a longtime internal specialist for GPU-related stuff who could have been side-tasked with creating a kludge or legacy shim hardware graphics support for that UB fork, but at this point there is nothing known to support that hypothesis.
I also have no insight, just like y’all, on whether Apple maintained internal support for a UB Snow Leopard beyond 10A432 — meaning, once the DVD for retail was approved for replication, all subsequent work on an internal UB build might have come to a close. Consequently, minor version updates would probably have been limited to Intel architecture only. But again, take all of this as only conjecture at best and fiction at worst.
EDIT to add: After reviewing that thesis, it appears the publicly (i.e., ADC) available 10A411 seed update build was used.
I concur on this, especially given that until SL Intel was fully out of the bag, the only platform that had full 64-bit OSX support was ... the G5 platform
Yes and no.
From examining binaries in the SL betas, we have seen an abundance of either “dual-architecture” (i386 and x86_64) or “tri-architecture” (i386, x86_64, and ppc) builds, but very few, if any, which also call out “ppc64” architecture. Separately, considering how Snow Leopard was still being built for 32-bit architecture despite being re-engineered for 64-bit complete support on systems with all-64-bit architecture and firmware (i.e., 64-bit Intel), an internal fork with UB support for PowerPCs probably kept that arm to 32-bit support to reach the broadest variety of PowerPC Macs in circulation.
Put another way: there was zero financial or strategic incentive for them to bring in a fourth architecture for Snow Leopard, even as a contingency, and making its binaries “quad-architecture” (i386, x86_64, ppc, and ppc64). If the UB contingency had to be used, Apple could still market Snow Leopard as a 64-bit OS from the ground up because, yes, it was 64-bit from the ground up
for Intel 64-bit Macs. The asterisk in the fine print would then clarify that it did not apply to 64-bit PowerPC Macs such as all the G5s.
So any ppc SL in the "just-in-case" drawer would have accounted for possible issues/delays in the development of the 64-bit Intel kernel and base system. They would have indeed made this a contingency plan right from the start of the development and later tossed it aside, relegating ppc development to a fork consisting of internal builds as 64-bit Intel development was making good progress.
Correct.
What happens if we run specific packages instead of trying to update the whole thing? Or it just is not designed to work this way in any case?
I tried this with the Xcode installer for 10A261, and it griped that the .pkg installer (I forget which one I tried) was not intended to be applied in that manner. Part of the Xcode installer contains a script which predetermines which secondary packages are to be used and which are to be skipped.
