Welcome to the Snow Leopard PowerPC Development thread!
This thread is the central hub for the technical development, testing and documentation required to reconstruct later releases of Mac OS X 10.6 Snow Leopard for PowerPC Macs.
The current practical development environment is the 10.6.8-derived Alpha 5 (A5) image.
This is not an untouched retail copy of Mac OS X 10.6.8, with PowerPC switched back on, it is an experimental community reconstruction combining:
Selected Mac OS X 10.5.8 components where a suitable later PowerPC implementation is not currently available;
Components rebuilt from Apple-released open source;
Targeted wrappers, compatibility components and other modifications required where interfaces changed between development version numbers
The long-term goal is to reduce substitutions wherever technically justified and reconstruct as much of the later official Snow Leopard software stack as possible from the appropriate Apple source generations while retaining PowerPC compatibility.
This is an experimental development project, not a finished operating-system release.
Results can vary according to:
Mac model;
CPU;
GPU;
storage/controller hardware;
network hardware;
image revision;
KEXT/framework versions;
local modifications;
installation and maintenance history.
A result demonstrated on one system should therefore not automatically be treated as universal.
For the earlier Developer Preview work and the mature 10A096 compatibility branch, see:
The principal Snow Leopard builds used by the project are related, but not interchangeable.
Build / branch
Role
Current value
10A096
Early Developer Preview / mature compatibility branch
Comparatively Leopard-proximate and extensively tested. The original thread contains a detailed component-by-component compatibility record.
10A190
Transitional reconstruction branch
Considerably more Snow-Leopard-proximate while remaining demonstrably bootable on PowerPC. Valuable working reference, donor environment and early Apple Open Source reconstruction platform.
10A222 and intermediate builds
Comparative / experimental bridge
Useful for identifying approximately when APIs, binaries and PowerPC implementation paths changed during Apple’s Snow Leopard development.
10A432
Retail Mac OS X 10.6.0 GM control point
Critical reference for determining what Apple actually shipped before comparing later reconstructed PowerPC components.
10.6.8 / A5
Current later-Snow-Leopard development branch
Primary public testing and reconstruction environment.
For the full history and relationship between these branches, see Post #2.
Important: labels such as “A5” identify a development lineage. They do not guarantee that every A5 installation circulating online or locally modified by a tester is byte-identical.
When reporting results, state the exact image source and any changes made after installation.
See Post #3 for the current documented Xcode/toolchain state rather than relying on older developer-tool packages linked elsewhere in the thread.
IMAGE INTEGRITY
10.6 PowerPC images has been mirrored and modified in several places over time.
When possible, record:
Code:
filename
source/mirror
file size
hash
date obtained
local modifications
Do not redistribute a locally modified image under the same filename while presenting it as an untouched copy of the public testing image.
INSTALLATION
Use a spare disk or partition and back up important data - before proceeding.
The established restore workflow is:
Prepare a PowerPC G4/G5 Mac with a working Leopard 10.5.8 installation.
Create or attach a separate target disk/partition for Snow Leopard.
Obtain the latest restore image.
Boot into Leopard.
Open Disk Utility.
Select the image and use Scan Image for Restore.
Restore the image to the target using Erase Destination / block-copy restoration.
Select the restored Snow Leopard volume using Startup Disk or the appropriate boot picker.
Boot the system and record the results
The deployment method itself is part of the test configuration.
If installation or boot fails, please report:
host OS used for the restore;
Disk Utility or other restore tool/version;
partition scheme;
target storage hardware/controller;
whether the image passed Scan Image for Restore;
the exact point at which boot failed.
Do not blindly run Apple Software Update on PowerPC Snow Leopard!
Snow Leopard updates can replace working PowerPC-compatible components with Intel-only or otherwise incompatible versions.
Update packages should instead be evaluated component-by-component.
Use caution with cache cleaners and invasive maintenance utilities.
Some cache rebuild/maintenance procedures have rendered experimental hybrid installations unbootable. Perform such experiments only on a clone or disposable installation.
CURRENT TECHNICAL STATE
The following table is a current snapshot of evidence, not a universal compatibility guarantee.
Status terminology
Status
Meaning
WORKING
Demonstrated working within the stated configuration.
PARTIAL
Some parts of the capability work while other parts remain defective or unverified.
REPRODUCED ISSUE
Failure has been reported repeatedly or directly observed.
LOCALISED
Evidence has narrowed the problem to a subsystem or interface, but the root cause is not necessarily closed.
WORKAROUND
A practical bypass exists while the underlying problem remains.
FIX CANDIDATE
A proposed repair has supporting evidence but still requires controlled validation/regression testing.
NEEDS TESTING
Evidence remains insufficient, conflicting, image-dependent or hardware-specific.
10.6.8_ppc “A5” subsystem status
Subsystem
State
Current evidence / useful testing
Boot / Aqua desktop
WORKING — development state
A5 boots to the graphical desktop on demonstrated G4 and G5 configurations. Exact hardware coverage remains incomplete.
Kernel / XNU
WORKING PPC RECONSTRUCTION
Project runtime evidence records Darwin 10.8.0 / xnu-1504.15.3~1/RELEASE_PPC. The corresponding Apple XNU source retains extensive PPC machine-dependent implementation. Exact image/kernel binding should still be recorded when testing.
Graphics / QE / CI
PARTIAL — hardware/framework dependent
Acceleration has been demonstrated on multiple configurations using PPC-compatible graphics components and compatibility work. Results depend upon GPU, bus, machine and effective framework set. Report QE and CI separately where possible.
Ethernet / AirPort
PARTIAL
Physical interfaces and bounded network connectivity work. AirPort association/link activity has been directly observed, but association does not prove DHCP, DNS, routing or discovery.
DHCP
REPRODUCED / IMAGE-CONFIGURATION DEPENDENT
Repeated reports remain. Static addressing is presently the better controlled baseline. Test DHCP separately from DNS and other networking layers.
DNS / UDP
REVISION / CONFIGURATION DEPENDENT
Earlier external-interface UDP failures are not a valid universal description of current A5. Record raw IP connectivity, DNS lookup and UDP behaviour independently.
Application Firewall / incoming services
LOCALISED / FIX CANDIDATE
Runtime logs show ALF socket-filter errors. Disabling/unloading ALF has restored incoming connectivity in at least one controlled configuration. This does not establish a general networking fix. A/B testing is requested.
AFP / SMB / Finder network discovery
REPRODUCED ISSUE / MULTI-LAYER
A concrete PPC file-sharing remediation bundle exists, but full provenance and runtime sufficiency remain unresolved. Test Finder discovery, direct mount, AFP/SMB and client/server direction independently.
NFS
WORKING ALTERNATIVE / WORKAROUND
NFS has worked in configurations where Finder/SMB paths remain problematic. Useful as both a practical alternative and network-stack positive control.
Removable media / Finder eject state
PARTIAL / LOCALISED
Media can successfully unmount at the filesystem/device layer while Finder retains a stale volume icon. Do not report this simply as “the disk does not eject” without checking actual mount state.
Finder ↔ DiskImages
PARTIALLY LOCALISED
A5-associated runtime evidence shows a Finder/DiskImages symbol/API failure involving DIHLCopyImageForVolume. Exact binary/version binding remains part of the investigation.
Authorization / root-owned files
REPRODUCED REGRESSION
Permission/authorization failures have been observed in A5-associated runtime evidence. Test one exact privileged edit/install workflow and compare with 10A190 and Intel Snow Leopard controls.
Bluetooth
REPRODUCED / PARTIALLY LOCALISED
Device discovery remains problematic. blued can start while the service-registration/discovery path remains defective. Include controller identity and logs.
Spotlight
REPRODUCED / PARTIALLY LOCALISED
Query failures are present in A5-associated runtime evidence. Test indexing, mds/mdworker and Spotlight/SystemUIServer query behaviour separately.
Quick Look / Finder Cover Flow
UNRESOLVED
Known graphical/UI defects remain. These should not automatically be merged with Spotlight, Finder eject or general graphics failures.
Sleep / thermal / shutdown
HARDWARE DEPENDENT / NEEDS TESTING
Reports differ by PowerBook/Power Mac model. Test sleep, wake, shutdown, fan behaviour and temperature monitoring separately and conservatively.
USB
PARTIAL / DEVICE-SCOPED ISSUES
A5 runtime evidence includes USB enumeration failure on a specific hub/device path. Do not generalise this to all USB hardware. Report exact topology/device.
AHCI / SATA / PCIe storage
HARDWARE-SPECIFIC / NEEDS TESTING
Some controller/KEXT combinations cause panics or non-boot conditions. Report exact Mac, controller and KEXT versions rather than treating AHCI as universally broken.
Printing / CUPS
PARTIAL
CUPS/open-source reconstruction has progressed, but residual architecture coverage and complete end-to-end printing remain insufficiently validated.
Java
SYSTEM CONTRACT UNRESOLVED
Availability of OpenJDK or another JVM is not equivalent to restoring Apple’s Snow Leopard Java system-framework contract. Test against the exact application/API requirement.
Professional applications
APPLICATION-SPECIFIC
Final Cut Pro, Compressor, Color, Avid, Adobe and other applications have different dependencies and must be tracked individually rather than through one “Pro Apps” status.
XNU / POWERPC SOURCE RETENTION
One of the clearer technical findings of the project is that:
Snow Leopard withdrawing PowerPC product support did not mean that all PowerPC machine-dependent implementation was immediately removed from Apple’s source tree.
The 10.6.8 XNU generation retains substantial explicit PPC code and build machinery.
PowerPC Ports/PPCPorts is a separate project, but its native Snow Leopard PowerPC software builds provide extremely useful real-world validation of the operating system and development environment.
HOW YOU CAN HELP
You do not need to be a kernel developer to contribute useful evidence.
What you have / can do
Useful contribution
A PowerPC G4 or G5
Install A5 on a spare disk and submit exact hardware-specific results.
An untouched retail 10A432 installation
Provide a read-only inventory of Apple’s original 10.6.0 shipping state: binaries, slices, hashes, dependencies, KEXT metadata, service definitions and package receipts/BOMs.
Software-development experience
Rebuild Apple Open Source components, investigate dependencies and interfaces, analyse Mach-O binaries, audit PPC-specific code and validate proposed fixes.
Networking experience
Help separate DHCP, DNS, UDP, routing, firewall, discovery, AFP, SMB and NFS behaviour through controlled packet/log testing.
PowerPC graphics hardware
Submit exact GPU/bus/Mac/framework results for QE, CI, OpenGL and application-level rendering.
Historical Apple material
Developer Previews, Kernel Debug Kits, DarwinBuild Roots, historical Xcode packages, build roots, old patches, attachments and intermediate Snow Leopard builds can all contain unique evidence.
Application testing time
Test individual Apple/professional/third-party applications with exact version and dependency information.
One of the most valuable contributions currently possible is access to an untouched retail Mac OS X 10.6.0 / build 10A432 installation.
This allows the project to distinguish:
Code:
what Apple published as source
≠
what Apple built
≠
what Apple shipped
≠
what later reconstructed A5 systems contain
Useful read-only evidence includes:
[]file paths and versions;
[]file and lipo architecture results;
[]SHA hashes;
[]otool dependencies/load commands;
[]KEXT versions and architecture;
[]launchd/service plists;
[]framework identities;
[]package receipts and BOM data;
selected system/developer-tool inventories.
Please preserve an untouched reference system as a control.
Once modified, the system may still contain useful evidence, but it can no longer serve as an unquestioned pristine shipping-state reference for altered paths.
CURRENT HIGH-VALUE TESTING AREAS
Area
Useful next test
Canonical A5 state
Record exact image source/hash, kernel identity, restore procedure and modifications before further testing.
10A432 reference
Untouched retail/GM binary, architecture and dependency inventory.
DHCP
Capture DHCP DISCOVER/OFFER/REQUEST/ACK plus configd/IPConfiguration logs on a clean known A5 state.
ALF / incoming services
Controlled ALF-loaded versus ALF-unloaded comparison using the same static network configuration; test SSH/VNC/file sharing independently.
AFP / SMB / Finder discovery
Separate automatic discovery, direct mounting, protocol and client/server direction.
Finder eject / DiskImages
Compare mount table/device state, Disk Arbitration notifications and Finder presentation for one controlled eject event.
Authorization
Reproduce one root-owned file edit or privileged installer operation and capture SecurityAgent/authorization logs.
Graphics
Exact Mac + GPU + bus + framework state; test QE/CI/OpenGL and specific APIs/applications independently.
Bluetooth
Controller-specific discovery test with KEXT/framework identity and blued/service logs.
Spotlight
Separate metadata indexing from Spotlight/SystemUIServer query/UI behaviour.
Sleep / thermal
Per-model sleep/wake/shutdown/fan/temperature testing with conservative safety limits.
Storage / USB
Exact controller/device/KEXT A/B testing; avoid generalising one hardware failure to the entire subsystem.
Printing
Inventory PPC architecture coverage and complete a real printer add → submit → finish-job test.
This is not an exclusive task list.
It highlights areas where an additional controlled test can presently resolve a meaningful uncertainty.
SUBMITTING A TEST RESULT
Please provide enough information for somebody else to reproduce your result.
Code:
SLPPC TEST REPORT
IMAGE
Build / image:
Revision:
Source / mirror:
Hash if known:
Modifications since restore:
HARDWARE
Mac model:
Machine identifier:
CPU:
RAM:
GPU:
Storage/controller:
Network hardware:
Other relevant PCI/AGP/CardBus/USB hardware:
SYSTEM
Kernel:
Boot arguments:
Relevant KEXT/framework replacements:
TEST
Subsystem/application:
Application version if relevant:
Expected:
Actual:
Exact reproduction steps:
CONTROL / COMPARISON
Leopard 10.5.8 / 10A096 / 10A190 /
clean A5 / alternate hardware / other:
Relevant logs/errors:
RESULT
Working /
Partial /
Failed /
Regression /
Needs Retest
Successful controls are as useful as failures.
For example:
Code:
raw IP works but DNS fails
NFS works but SMB fails
device unmounted but Finder still displays it
Wi-Fi associates but DHCP fails
These observations isolate the failing layer much more effectively than reporting only:
Code:
networking is broken
Finder is broken
Wi-Fi is broken
DEVELOPMENT / SOURCE-BUILD REPORTS
Detailed build methodology and the full reproducible development-report template are maintained in:
PowerPC macOS development and historical toolchain resources.
When rebuilding an operating-system component, use the source generation appropriate to the target component/build wherever that can be established.
A newer source release is not automatically a better replacement.
Likewise:
Apple publishing a source project does not by itself establish the exact binary Apple shipped in a particular OS build.
Shipping-state questions should be checked against actual binaries, packages, manifests, receipts or untouched systems where possible.
THREAD SCOPE
This development thread covers:
[]Mac OS X 10.6.x PowerPC reconstruction;
[]XNU and IOKit;
[]system frameworks and libraries;
[]Apple Open Source reconstruction;
[]system applications and services;
[]hardware compatibility;
[]bugs and diagnostics;
[]controlled fixes and workarounds;
[]10.6.8/A5 integration and testing;
[]the Xcode/Darwin development environment required to support that work.
Third-party software ports, MacPorts and PowerPC Ports/PPCPorts are highly relevant sources of evidence but remain separate projects.
Please link relevant findings rather than treating those projects as part of SLPPC itself.
PROJECT HISTORY
For the full history of the modern Snow Leopard PowerPC effort—from the rediscovery of the Developer Previews through 10A096, 10A190, 10A222, retail-generation XNU reconstruction and A5—see:
This software is experimental and is known to contain defects.
Do not rely upon experimental disk images for important data or services.
Use a spare disk or partition and preserve backups.
Community-created images, patches, rebuilt binaries and instructions are provided for development, testing, research and preservation without warranty.
By participating in testing you accept responsibility for protecting your own hardware and data.
The most useful contribution is a reproducible result—working or broken—with enough information for somebody else to test it again.
The Snow Leopard PowerPC project did not begin as an attempt to create a new operating system - instead it began with a simpler question:
‘How much of Apple’s unfinished PowerPC work on Snow Leopard could still be recovered, understood and made useful on real PowerPC Macs?’
What followed gradually evolved from modifying Apple’s early Snow Leopard Developer Previews, into a much broader reconstruction effort, involving XNU, Apple Open Source projects, frameworks, system services, developer tools and eventually the later retail generations of Mac OS X Snow Leopard.
The original PowerPC Snow Leopard research and Developer Preview project is documented in:
This thread was later created to better concentrate the increasingly specialised development of later Snow Leopard, 10.6.8, Xcode and associated Darwin components.
THE IMPORTANT SNOW LEOPARD BUILDS
The builds used in this project should not be understood simply as progressively newer versions of the same community installation. Instead, they represent different stages of Apple’s Snow Leopard development and consequently expose different PowerPC compatibility boundaries.
Build
Role in the project
10A096
Early Developer Preview and mature compatibility/stability branch. Close to Leopard and retains extensive PowerPC-compatible material.
10A190
Later transitional Developer Preview and major early source-reconstruction platform. More representative of Snow Leopard, but with greater PPC divergence.
10A222 / intermediate builds
Comparative bridge builds useful for determining approximately when particular PPC implementations and component generations changed.
10A432
Retail 10.6.0 GM baseline and a critical reference point for later reconstruction.
10.6.8 / A5
Current practical later-Snow-Leopard PowerPC reconstruction and development environment.
The relationship is therefore better represented as several complementary branches, than as one linear upgrade path.
2020 — REDISCOVERY
In March 2020, @Larsvonhier encountered material showing an early Snow Leopard Developer Preview running on PowerPC hardware.
Early investigation established that at least some pre-release Snow Leopard builds retained sufficient PowerPC-compatible code to reach a usable graphical system once the appropriate Leopard-era boot and hardware-support components were supplied.
Julian Fairfax and @parrotgeek1 contributed an early 10.6 PPC.sh approach which gave experimenters a practical route to modifying the Developer Preview installations.
This began the modern community investigation of Snow Leopard on PowerPC.
APRIL–MAY 2020 — 10A096 AND SYSTEMATIC COMPONENT TESTING
Early work initially concentrated heavily on 10A096.
@vddrnnr began systematically testing Tiger- and Leopard-era components within the Developer Preview.
@B S Magnet subsequently expanded this into a much more comprehensive and disciplined compatibility programme.
The resulting tables and Wiki documentation in the original thread became one of the strongest operational records produced by the project, documenting working replacements, conditional results, failures and later revisions to earlier conclusions.
@Larsvonhier contributed extensive KEXT/build comparisons, while @jimjamyaha and other testers contributed binary, architecture and hardware observations.
@ASentientBot also played an important role in preserving otherwise difficult-to-obtain development material.
The 10A096 branch established a methodology which remains useful:
Code:
change one variable
→ test it
→ compare against a known state
→ document the result
→ revise the conclusion when stronger evidence appears
10A096 therefore remains more than an historical Developer Preview. It is the project’s mature early-build compatibility branch and a useful control when comparing later Snow Leopard behaviour.
APRIL–MAY 2020 — 10A190
The project soon moved further into Snow Leopard development with 10A190.
@weckart demonstrated that 10A190 could also be installed and booted on PowerPC using the Leopard BootX and PowerPC hardware-support approach developed during the earlier work.
On 3 May 2020, @Larsvonhier provided a pre-installed 10A190 environment, making the later Developer Preview substantially easier for others to investigate.
10A190 proved particularly important because it contained more of the developing Snow Leopard operating system than 10A096 while retaining enough PowerPC support to remain experimentally usable.
That made it less forgiving—but also more valuable for understanding the architecture which would eventually become retail Snow Leopard.
Around this period @vddrnnr also demonstrated software compilation using Snow Leopard-era Xcode 3.2 tools.
That raised an important question:
‘Instead of replacing every incompatible component with an older Leopard binary, could the missing Snow Leopard component itself be rebuilt for PowerPC?’
MAY 2020 — APPLE OPEN SOURCE RECONSTRUCTION
On 13 May 2020, @ChrisCharman joined the forum after following the existing work and began investigating Apple’s released source code as another route to reconstruction.
Apple’s historical Darwin/macOS sources are now particularly accessible through:
[/CENTER]
‘Which source project produces the missing component?’
‘Which version belongs to the target Snow Leopard generation?’
‘Does its PowerPC implementation still exist?’
‘Can it actually be compiled and linked for PPC?’
‘Does the resulting binary satisfy the interfaces expected by the later Snow Leopard system?’
‘Does it work correctly at runtime?’
By 22 May 2020, early source-build work had demonstrated that Apple Open Source components could be rebuilt and used within 10A190.
This marked the beginning of the project’s source-reconstruction branch.
The development model was no longer limited to:
Code:
[/CENTER]
replace Snow Leopard file X
with Leopard file Y
As early as May 2020, it was recognised that the project could naturally diverge into two useful directions.
One path concentrated on refining the comparatively Leopard-proximate 10A096 environment.
The other pursued 10A190 and increasingly later Snow Leopard components.
That is effectively what happened.
Branch
Primary value
10A096
Highly tested Developer Preview compatibility and comparatively stable end-user environment.
10A190 and later
Reconstruction of progressively later Snow Leopard architecture and components.
Neither invalidates the other.
They answer different engineering questions and provide useful controls for each other.
2020–2022 — FROM FILE SWAPS TO SYSTEM CONTRACTS
As more complex components were rebuilt and exchanged, it became increasingly obvious that architecture compatibility alone was insufficient. Snow Leopard components participate in versioned relationships involving:
APIs;
ABIs;
Mach-O symbols and dependencies;
framework versions;
service protocols;
generated build artefacts;
kernel/userspace contracts.
A PowerPC binary may compile and link successfully, while still being unsuitable for the system attempting to use it. Likewise, substituting a Leopard framework may repair one consumer while removing interfaces expected by another Snow Leopard component. This established an important project principle:
PowerPC architecture compatibility is necessary, but the surrounding software contract must also be satisfied.
Historical build infrastructure also became increasingly important.
DarwinBuild roots, Xcode versions, SDKs, cctools, ld64, compiler behaviour and generated intermediate files can all materially affect a supposedly identical source build.
2024 — GRAPHICS COMPATIBILITY AND STUBBING
Development accelerated significantly again in 2024.
On 20 April, @educovas shared graphics-acceleration work using a compatibility approach derived from tooling and techniques previously developed by @ASentientBot.
Symbols exported by Leopard and later Snow Leopard framework generations could be compared—for example using nm—and missing interfaces identified.
Compatibility wrappers or stubs could then allow selected newer consumers to link against older PowerPC-capable implementations.
This established a useful third strategy between:
Code:
use the old framework unchanged
and:
Code:
reimplement the entire newer framework
However, it also highlighted another critical boundary:
A symbol stub which satisfies the linker does not automatically implement the behaviour expected by the caller.
Linkage success therefore remains an intermediate result. Runtime semantic validation is still required.
APRIL 2024 — 10A222
On 28 April 2024, @educovas provided an experimental modified 10A222 environment combining PowerPC-compatible material from 10A190 with rebuilt Apple Open Source components.
10A222 demonstrated that useful PowerPC reconstruction could move beyond the two Developer Previews which had already reached complete graphical boot. It also exposed the gradual nature of Apple’s architecture transition.
PowerPC support did not disappear from every part of Snow Leopard simultaneously.
XNU, KEXTs, frameworks, applications, Unix tools and developer tools changed at different points.Intermediate builds are therefore valuable because they help bracket those transitions.
Testing also showed that different 10A222 kernel configurations produced different results on some G4 hardware, reinforcing the need to distinguish kernel configuration from userland state.
MAY 2024 — THE 10A432 XNU BREAKTHROUGH
During May 2024, @educovas reported reaching a graphical environment using a newly built 10A432-generation XNU kernel together with reconstructed Apple Open Source components and compatible material from earlier Snow Leopard builds.
Work in this period included components such as:
XNU;
file;
notifyd;
securityd;
kext_tools;
DirectoryService;
autofs.
Networking remained a major obstacle, but the kernel result materially changed the understood boundary of the project.
Later Snow Leopard PowerPC development was no longer necessarily limited to using kernels from Apple’s original PPC-capable Developer Previews.
@ChrisCharman subsequently followed the published source modifications and independently reproduced a successful PowerPC build of the 10A432-generation kernel.
The significance should be expressed precisely:
A retail-generation Snow Leopard XNU could be rebuilt for PowerPC.
That did not mean the complete retail Snow Leopard userland was already PowerPC-compatible.
It demonstrated that the kernel itself was no longer the absolute boundary previously assumed.
XNU AND SURVIVING POWERPC SOURCE
Subsequent investigation has strengthened this finding.
The final Snow Leopard XNU source generation used by 10.6.8:
still contains extensive explicit PowerPC machine-dependent implementation and PPC build machinery.
This produces an important distinction:
Apple withdrawing PowerPC as a supported Snow Leopard product did not mean that all PowerPC implementation was immediately removed from the source tree.
At the same time:
source retention is not equivalent to working runtime support.
The relevant implementation must still survive each stage:
The amount of Apple Open Source reconstruction increased substantially during 2024.
@educovas reported building hundreds of released Apple source projects and integrating many resulting components into experimental later-Snow-Leopard PowerPC installations.
Other contributors investigated individual packages, missing build dependencies and difficult source projects.
At this stage, describing the project simply as “patching a Developer Preview” was no longer accurate.
Later development involved interactions between hundreds of components and their corresponding source/build generations.
A simple replacement list was no longer sufficient to describe the system.
OCTOBER 2024 — THE DEVELOPMENT THREAD
By late 2024, the original thread contained several increasingly distinct streams:
[]10A096 compatibility and end-user testing;
[]10A190 development;
[]later-build reconstruction;
[]XNU;
[]Apple Open Source builds;
[]Xcode and toolchains;
[]MacPorts/PPCPorts;
[]application compatibility.
The lower-level development work was increasingly difficult to follow amongst the wider Developer Preview discussion.
The original thread remains the primary historical and Developer Preview resource.
This thread became the engineering hub for later Snow Leopard, 10.6.8, A5, XNU, Apple Open Source and native development-tool work.
THE 10.6.8 / ALPHA 5 DEVELOPMENT LINE
Continued reconstruction eventually produced a usable 10.6.8-derived PowerPC development environment.
The publicly distributed Alpha 5 (A5) lineage combines material from several provenances, including:
[]10.6.8 system components;
[]PowerPC-compatible material retained from 10A190;
[]selected Leopard implementations;
[]PowerPC builds of Apple Open Source projects;
[]framework/interface compatibility work;
[]replacement PowerPC Unix and developer components.
A5 should therefore be understood as an experimental reconstruction platform rather than as an untouched 10.6.8 installation with one patch applied.
Different revisions and locally modified installations can differ materially.
For that reason, current testing increasingly records exact image, binary, framework and KEXT state.
2025–2026 — NATIVE DEVELOPMENT ON SNOW LEOPARD POWERPC
Another important milestone was restoration of a practical native PowerPC development toolchain on 10.6.8.
On 20 January 2025, @barracuda156 documented a tested minimum configuration based on standard Xcode 3.2.6 plus targeted replacements for unusable developer tools.
The separate PowerPC Ports project has since continued extensive native Snow Leopard PowerPC software and toolchain development.
PowerPC Ports is not part of SLPPC, but its use of native 10.6.8 PowerPC provides valuable real-world validation of the reconstructed operating system and development environment.
For the maintained Xcode/toolchain documentation, see:
It makes experiments reproducible and prevents a configuration-specific success from silently becoming a universal claim.
Current investigation therefore distinguishes, for example:
[]DHCP from DNS and general network connectivity;
[]network transport from firewall behaviour;
[]Finder discovery from AFP/SMB/NFS connectivity;
[]successful disk unmount from stale Finder UI state;
[]GPU-specific acceleration from universal graphics compatibility;
[]controller-specific AHCI failures from universal storage claims;
[]PPC source existence from PPC code in the final linked binary;
[]symbol existence from consumer visibility;
successful compilation from validated runtime behaviour.
WHERE THE PROJECT STANDS NOW
The objective is no longer simply:
“Make Snow Leopard boot on a PowerPC Mac.”
That milestone was crossed years ago.
The present objective is closer to:
Reconstruct the latest practical Snow Leopard environment for PowerPC while determining exactly which Apple components, source generations, build tools and compatibility interfaces are required to make it reproducible and functionally correct.
Branch
Continuing value
10A096
Mature Developer Preview compatibility branch and strong historical control.
10A190
Working transitional Snow Leopard reference and early source-reconstruction platform.
10A222 / intermediate builds
Evidence for when particular architectural changes occurred.
10A432
Retail 10.6.0 control point and major reconstruction reference.
10.6.8 / A5
Current practical later-Snow-Leopard PowerPC development environment.
Together they form a useful historical sequence for studying how PowerPC support was progressively withdrawn—and which parts can still be reconstructed.
ACKNOWLEDGEMENTS
Snow Leopard PowerPC has always been a community effort.
Major contributions include work by:
[]@Larsvonhier — original project/thread creation, early Developer Preview investigation, build/KEXT comparison and 10A190 distribution;
[]Julian Fairfax and @parrotgeek1 — early scripting which enabled wider experimentation;
[]@vddrnnr — systematic early component and development testing;
[]@B S Magnet — extensive long-term 10A096 testing, compatibility analysis and Wiki documentation;
[]@ASentientBot — preservation work and techniques later used in compatibility investigation;
[]@jimjamyaha, @weckart and other early testers — hardware, binary and build investigation;
[]@educovas — major later-build, graphics, XNU and Apple Open Source reconstruction work;
[]@barracuda156 — Snow Leopard PowerPC compiler/toolchain development, PowerPC Ports and extensive platform investigation;
@ChrisCharman — Apple Open Source reconstruction, later-build/XNU investigation, A5 integration/testing and coordination of this development thread.
Many others have supplied hardware testing, code, images, mirrors, historical material, build logs, bug reports, corrections and failed experiments which prevented the same dead ends being repeated.
If a significant contributor or piece of work is missing, this history should be corrected.
It is intended to remain a living record rather than a closed credits list.
CONTINUING THE WORK
For current OS state, A5, installation, compatibility and reproducible testing:
The project has progressed because successful results, failures and corrections were documented and shared. Reproducible evidence remains one of the most useful contributions anyone can make.
This post documents the development environment used to build software and reconstruct operating-system components on Mac OS X 10.6 Snow Leopard PowerPC.
It covers:
[]Xcode 3.2.x;
[]GCC and compiler support;
[]cctools and darwin-xtools;
[]assembler and linker reconstruction;
[]GNU/Apple make;
[]SDKs and deployment targets;
[]Mach-O inspection and verification;
[]DarwinBuild;
[]Apple Open Source reconstruction;
[]PowerPC Ports/PPCPorts as an external native-development ecosystem;
[]known Intel-only or otherwise unsuitable developer tools;
[]native versus Intel-hosted PPC cross-compilation;
reproducible build reporting.
Three separate questions must be distinguished:
Code:
Can the Xcode IDE itself run?
Can the command-line development environment build PowerPC software?
Can a particular Apple source project be reproduced correctly?
These are related, but they are not equivalent claims.
A working compiler does not prove that Interface Builder works.
A working Xcode application does not prove that every command-line utility has a PowerPC slice.
A successful source compile does not prove that the resulting system component behaves correctly when installed.
CURRENT STATUS AT A GLANCE
Capability
Current state
Notes
Xcode 3.2.6 base installation
USABLE FOUNDATION
The standard Snow Leopard release provides the principal compiler, headers, SDK and developer-tree foundation used by the current 10.6.8 PPC environment.
Full Xcode 3.2.6 IDE
PARTIAL / NOT FULLY PPC-RECONSTRUCTED
The release contains proprietary Intel-only components. A usable command-line toolchain does not establish complete native IDE parity.
Xcode 3.2 from 10A190
NATIVE PPC / HISTORICAL DEVELOPMENT OPTION
Runs natively on the PowerPC-capable Developer Preview and remains useful for comparison and selected native GUI development, but is older and has known limitations.
gcc
WORKING
Demonstrated in the reconstructed 10.6.8 native development environment.
as
WORKING AFTER TOOLCHAIN PREPARATION
PowerPC-capable assembler is provided through reconstructed/replacement Darwin tooling.
ld
WORKING AFTER TOOLCHAIN PREPARATION
Historically validated using PPC-compatible ld64 97.17; newer maintained darwin-xtools paths also exist.
make
WORKING
PowerPC GNU/Apple make 3.81 has been demonstrated as part of the minimum native environment.
nm / ar / ranlib / strip / otool / lipo / libtool
AVAILABLE THROUGH CCTOOLS / DARWIN-XTOOLS
Used both to construct Mach-O binaries and to verify produced artefacts.
m4 / gm4 / bison and additional utilities
CONSUMER-DEPENDENT
Some Xcode-installed copies are unsuitable for native PPC. Replace or rebuild when an actual consuming build demonstrates the requirement.
Native third-party software builds
WORKING
Extensively exercised through PowerPC Ports/PPCPorts and individual native builds.
Apple OS component reconstruction
PROJECT-SPECIFIC
Depends on source generation, generated/private dependencies, build tooling and runtime contracts. No universal Apple Open Source recipe exists.
Intel Snow Leopard PPC cross-build
VALID FALLBACK / CONTROL
Useful where proprietary Xcode GUI tools or build-system components cannot presently be reproduced natively on PPC.
THE IMPORTANT DISTINCTION: XCODE VS THE TOOLCHAIN
It is tempting to summarise the current situation as:
“Xcode 3.2.6 works on PowerPC.”
That is too broad.
A more accurate statement is:
The standard Xcode 3.2.6 installation can provide the foundation for a usable Snow Leopard 10.6.8 PowerPC development environment once essential Intel-only or otherwise unsuitable command-line tools are replaced or reconstructed.
Therefore:
Code:
Xcode 3.2.6 installed
≠
every Xcode executable works on PPC
working gcc/as/ld/make
≠
complete Xcode IDE compatibility
source builds successfully
≠
runtime behaviour is correct
When reporting development results, always identify the actual tools which were executed.
XCODE VERSIONS RELEVANT TO SLPPC
Xcode generation
Target environment
Role in this project
Xcode 3.1.4
Leopard 10.5.8
Correct late Xcode generation for Leopard. Useful as a Leopard control but should not be treated as the preferred Snow Leopard development environment.
Xcode 3.2 — 10A190 Developer Preview
10A190 PPC
Native PowerPC Xcode environment. Useful for comparison, historical source builds and some GUI development. Older than the retail Snow Leopard toolchain.
Xcode 3.2.6
10.6.8
Primary foundation for current 10.6.8/A5 development. Compiler/header/SDK base is useful, while selected developer tools require PPC replacement.
Xcode 4.2 for Snow Leopard
Intel Snow Leopard
Useful as a later comparative source of SDK/compiler/tool material. Apple’s release requires an Intel host and it is not the native SLPPC baseline.
Install Xcode before replacing the required command-line tools.
Do not interpret installation success as proof that every binary within /Developer is PowerPC-compatible.
NATIVE XCODE 3.2 FROM 10A190
The Xcode 3.2 generation supplied with 10A190 remains important because it runs in an environment where Apple still retained substantially more PowerPC support.
It can therefore provide:
[]a native historical development environment;
[]PowerPC-capable components absent from later releases;
[]a behavioural comparison against Xcode 3.2.6;
[]a donor/reference point when determining where Apple removed PPC support.
However, it should not simply be copied wholesale into 10.6.8.
Some later Snow Leopard projects expect newer SDK, compiler, linker or Interface Builder behaviour.
Conversely, there have also been cases where earlier Xcode generations succeed where later ones do not.
For this reason the correct question is normally:
Which exact component of Xcode is required by this build?
rather than:
Which complete Xcode release should replace the current one?
As of the September 2026 review, the maintained Snow Leopard sequence is conceptually:
[]Install standard Xcode 3.2.6.
[]Install/prepare darwin-xtools to provide suitable assembler, linker and related tools.
[]Install a working Apple make.
[]Replace bsdtar where required by the current A5/PowerPC Ports environment.
[]Install a modern bootstrap curl because Apple’s bundled curl cannot communicate reliably with current HTTPS infrastructure.
[]Install the PowerPC Ports base under /opt/local.
For a fuller source-development environment, replace/rebuild additional tools such as m4 and bison, including copies under /Developer/usr/bin where consuming builds invoke them.
Because this external toolchain evolves, always use the maintained PowerPC Ports guide for its latest exact commands and package versions.
Do not freeze transient PowerPC Ports package versions into SLPPC as though they were part of the operating-system release.
POWERPC PORTS / PPCPORTS
PowerPC Ports is a separate project providing modern software and an actively maintained ports environment for PowerPC macOS.
The project combines modified Darwin open-source components including:
[]cctools;
[]ld64;
selected dyld headers/support material.
Its purpose includes enabling newer development tools on older Darwin/macOS releases.
Of particular relevance to PowerPC, darwin-xtools explicitly restores and extends PPC/PPC64 support and incorporates heavily modified Xcode 3.2.6-era PowerPC support together with subsequent fixes.
It also addresses compatibility with output produced by newer GCC/LLVM generations.
This is important because stock Xcode-era tools may understand the object formats generated by their contemporary Apple compiler while failing on constructs generated by much newer compilers.
Therefore:
The best tool for rebuilding a 2009 Apple operating-system component and the best tool for compiling modern 2026 software are not necessarily the same toolchain.
Use toolchain versions according to the consuming build.
LD64 — THE MACH-O LINKER
Apple’s ld64 is the Mach-O static linker used by later Xcode generations.
The January 2025 minimum native toolchain deliberately used PPC-compatible ld64 97.17.
That choice was conservative:
[]it corresponds closely to the late Xcode 3.2.x environment;
[]PowerPC support could be restored;
[]LTO was disabled;
[]it avoided introducing unnecessary behavioural differences from substantially newer linkers.
Later darwin-xtools generations can be useful, particularly for modern compilers.
However:
newer does not automatically mean more suitable for rebuilding an old Apple source project.
Record linker identity with every significant build.
Useful checks:
Code:
which ld
type -a ld
ld -v
file “$(which ld)”
otool -L “$(which ld)”
MAKE
Snow Leopard Apple source projects frequently assume GNU/Apple make 3.81-era behaviour.
The current preferred strategy is consumer-driven replacement.
Do not replace every tool merely because it might eventually be required.
Instead:
Code:
attempt real build
→ record first failing tool
→ identify exact path invoked
→ inspect architecture/version
→ replace or rebuild that tool
→ rerun identical build
This produces both a smaller modification surface and stronger evidence about what the environment actually requires.
COMPILERS
The standard Xcode 3.2.6 installation provides the compiler/header foundation used by the demonstrated 10.6.8 PowerPC development environment.
For reconstructing Snow Leopard-era Apple software, Apple’s GCC 4.x toolchain remains particularly important because many projects were written and tested against Apple-specific GCC behaviour.
Useful checks:
Code:
which gcc
gcc –version
which g++
g++ –version
xcodebuild -version
Modern PowerPC software development can use substantially newer GCC generations through PowerPC Ports.
This creates two legitimate but different use cases:
Goal
Preferred principle
Reproduce Apple Snow Leopard component
Prefer the historically appropriate compiler/toolchain unless evidence demonstrates a newer compiler is required or safe.
Build modern third-party software
Use a maintained modern GCC/toolchain where appropriate.
Do not assume a component which builds with GCC 14, for example, is necessarily equivalent to Apple’s original Snow Leopard artefact.
Conversely, do not assume Apple’s 2009 compiler is appropriate for modern C++ software.
SDKs AND DEPLOYMENT TARGETS
A reproducible build report should always identify the SDK and deployment target.
First inspect the available SDKs:
Code:
ls -la /Developer/SDKs
For a normal 10.6-targeted build, common settings include:
Do not blindly inject all of these into every project.
Apple build systems vary considerably between source projects and generations.
Record exactly which variables were required for the successful build.
ppc vs ppc64
For the SLPPC operating-system reconstruction, ppc is the principal target unless there is a specific reason to build ppc64.
ppc64:
[]requires G5-class hardware;
[]may exercise different source paths;
[]may have different library/framework availability;
[]should therefore be treated as an explicit separate architecture target.
Do not silently assume:
Code:
ppc success = ppc64 success
or vice versa.
WHICH TOOL ACTUALLY RAN?
This is one of the most important diagnostics in the entire native development environment.
Before replacing a supposedly broken tool:
Code:
which
type -a
file
lipo -info
otool -hv
For Xcode-managed tools also inspect:
Code:
xcode-select -print-path
xcrun -find
where supported.
A typical system may contain several copies of the same nominal utility:
For a specific architecture’s symbol table where supported:
Code:
nm -arch ppc ./binary
The questions to answer are:
[]Is this actually a Mach-O executable/library/bundle?
[]Does it contain a ppc slice?
[]Is the expected file type produced?
[]What dylibs/frameworks does it link against?
[]Are expected symbols present?
[]Does the install name match the intended target?
Does it contain unexpected Intel-only dependencies?
For operating-system reconstruction, architecture verification is only one stage:
A recurring source of confusion is treating symbol presence as one binary state.
There are several distinct questions:
Code:
Does the function exist in source?
Was its source file compiled?
Was the resulting object linked into the final binary?
Does the final Mach-O export the symbol?
Is it exported for the PPC architecture?
Is it visible to the particular consumer/KEXT?
Does the implementation behave correctly when called?
For example, useful tools include:
Code:
nm
otool
lipo
strings
jtool / jtool2
depending on the analysis being performed.
A successful nm lookup is useful evidence, but it should be described precisely.
SYSTEM TOOLS VS XCODE TOOLS
Snow Leopard can contain more than one generation of Apple’s development tools.
The distinction is especially important when reconstructing the system itself.
The OS may ship one generation under:
Code:
/usr/bin
while Xcode installs a newer developer generation beneath:
Code:
/Developer
For example, Apple’s released source archive contains:
associated with the Snow Leopard OS generation, while later Xcode 3.2.x development tools use later cctools generations.
Therefore the question:
“What version of cctools does Snow Leopard use?”
may be underspecified.
More useful questions are:
Code:
Which OS build?
Which Xcode build?
Which path?
Which exact binary?
Which source producer?
Which consumer invokes it?
The same principle applies to other duplicated developer components.
GUI / COCOA DEVELOPMENT AND INTERFACE BUILDER
Command-line development is currently better understood than complete native Xcode GUI compatibility.
Xcode 3.2 from the 10A190 generation runs natively on PowerPC and works for many development tasks.
However, later projects can depend upon newer:
[]Interface Builder behaviour;
[]XIB formats;
[]Cocoa development tools;
[]project-file formats;
compiler/build-system behaviour.
The retail Xcode 3.2.6 distribution contains proprietary components for which a complete native PPC equivalent is not currently available.
This means a GUI application can encounter a development-tool failure even when its actual source code compiles correctly.
One observed example was a Cocoa project whose code could be compiled for PPC but whose XIB resources were not handled correctly by the native older development environment.
For these cases, a useful control/fallback is:
Code:
Intel Mac / VM
running Snow Leopard 10.6.8
+
Xcode 3.2.6
+
build target: ppc
If an identical project succeeds there but fails on native SLPPC, the problem may lie in the native development tools rather than the application source itself.
Cross-compilation is therefore not a failure of the native project—it is an important diagnostic control when proprietary developer components cannot yet be reconstructed.
APPLE OPEN SOURCE DEVELOPMENT TOOLS
Apple has released source for a large portion of its Darwin development toolchain.
[]associate OS builds with exact Apple source-project versions;
[]download source and dependency roots;
[]construct controlled build environments;
[]install headers separately;
[]record build results;
[]record produced files and Mach-O dependencies;
query which source project produced a file.
Conceptually, this makes DarwinBuild extremely relevant to SLPPC.
For example:
Code:
darwinxref -b version
can help determine the source identity expected by a historical Darwin build where the relevant build metadata survives.
However, historical DarwinBuild should not be treated as a turnkey modern PPC Snow Leopard builder.
Its own branches and assumptions changed with Darwin releases, and historical infrastructure/download locations have disappeared or moved.
For an Apple operating-system or developer-tool component, a disciplined build generally starts with provenance rather than compiler flags.
Recommended process:
Code:
[LIST=1]
[*]Identify the binary/component being replaced.
[*]Identify the source project which produces it.
[*]Identify the correct source version for the target OS/Xcode build.
[*]Identify build-time dependencies and generated/private headers.
[*]Establish whether a PPC implementation exists.
[*]Attempt the least-modified historical build.
[*]Record the first real blocker.
[*]Patch only the demonstrated blocker.
[*]Verify the produced PPC artefact.
[*]Install into a controlled test system.
[*]Test the actual consuming subsystem.
Apple published source
≠
Apple build input completely recovered
≠
Apple shipping binary identified
≠
A5 component identified
Apple sometimes released sources at different times and under different release collections.
The same project may also appear separately in:
[]an OS release;
[]an Xcode Developer Tools release;
[]an adjacent OS release;
[]a later GitHub preservation repository.
When exact provenance matters, compare:
[]source release/tag;
[]binary version strings;
[]Mach-O architecture;
[]install location;
[]package receipts;
[]DarwinBuild metadata;
[]dependencies;
[]hashes where available.
This is especially important when rebuilding foundational tools such as cctools and ld64.
A MINIMUM ENVIRONMENT CHECK
Before attempting a significant source build, capture the developer environment.
Suggested starting inventory:
Code:
sw_vers
uname -a
uname -m
xcodebuild -version
xcode-select -print-path
gcc –version
which gcc
which as
which ld
which make
type -a gcc
type -a as
type -a ld
type -a make
ld -v
make –version
ls -la /Developer/SDKs
The native developer tree is not yet completely mapped.
There are two poor strategies:
Code:
replace nothing because Xcode installed successfully
and:
Code:
replace every Intel binary before attempting a build
The first leaves hidden PPC blockers.
The second destroys evidence about which replacement was actually necessary and increases the risk of introducing version mismatches.
The preferred approach is:
controlled, consumer-driven replacement.
If a build fails:
[]record the exact error;
[]identify the exact executable invoked;
[]inspect its architecture/version;
[]identify its producer/source;
[]replace or rebuild only when justified;
[]rerun the same build;
record whether the failure moved or disappeared.
CURRENT SLPPC TOOLCHAIN RESEARCH PRIORITIES
The developer-tool branch currently has several useful unresolved evidence targets.
Priority
Task
Why it matters
T1
Recover the exact original January 2025 installer/package bytes where possible.
Allows hashes, payload paths, binary architecture and original package identity to be established.
filename
file size
SHA-1
SHA-256
date obtained
original source URL
archive contents
package receipts
Do not repackage the original before hashing it.
SUBMITTING A DEVELOPER TOOL REPORT
Code:
SLPPC DEVELOPER TOOL REPORT
OS build / image:
Image revision:
Machine:
CPU:
Xcode:
Xcode source:
Developer directory:
Tool being tested:
Exact path:
Version:
Architecture:
Source/project version if known:
SDK:
Deployment target:
ARCHS:
Original problem:
Exact command:
Exact error:
Replacement/rebuild used:
Source URL/tag:
Patch/diff:
Build commands:
file output:
lipo output:
otool output:
Result after replacement:
Working /
Partial /
Failed /
Regression /
Needs further testing
Notes:
SUBMITTING AN APPLE SOURCE BUILD
Code:
SLPPC APPLE SOURCE BUILD REPORT
Target OS build:
Target component/path:
Apple project:
Exact source version/tag/archive:
Why this source version was selected:
Build host:
Host OS:
Xcode:
Compiler:
Assembler:
Linker:
Make:
SDK:
ARCHS:
MACOSX_DEPLOYMENT_TARGET:
Required dependencies:
Private/generated headers:
Patches:
Exact build commands:
Produced artefacts:
file:
lipo:
otool -L:
relevant nm/symbol results:
Installation path:
Installation method:
Runtime consumer tested:
Expected behaviour:
Actual behaviour:
Validation stage reached:
SOURCE IDENTIFIED /
PPC SOURCE PRESENT
[SIZE=5][B]RECOMMENDED REPRODUCIBLE BUILD WORKFLOW[/B][/SIZE]
For an Apple Open Source component or other system-level project, a useful development workflow is:
[TABLE]
[TR][TH]Stage[/TH][TH]Action[/TH][/TR]
[TR][TD][B]1 — Define the target[/B][/TD][TD]Record the exact Snow Leopard build, component and intended architecture before modifying source.[/TD][/TR]
[TR][TD][B]2 — Establish provenance[/B][/TD][TD]Identify the exact source project/version which produces the target component. Do not assume the newest available source is correct.[/TD][/TR]
[TR][TD][B]3 — Establish a control[/B][/TD][TD]Where possible, capture the equivalent untouched Apple binary, package, Root or known-good earlier implementation for comparison.[/TD][/TR]
[TR][TD][B]4 — Identify dependencies[/B][/TD][TD]Determine required headers, libraries, build-only tools, generated files and producer projects before altering source.[/TD][/TR]
[TR][TD][B]5 — Freeze the build environment[/B][/TD][TD]Record compiler, assembler, linker, make, SDK, PATH, deployment target and relevant architecture/build variables.[/TD][/TR]
[TR][TD][B]6 — Apply the smallest justified change[/B][/TD][TD]Restore PPC build selection, assembly, endian handling or interface compatibility only where evidence identifies the requirement.[/TD][/TR]
[TR][TD][B]7 — Clean build[/B][/TD][TD]Use clean OBJROOT/SYMROOT/DSTROOT outputs when changing toolchain, SDK, architecture, dependencies or source patches.[/TD][/TR]
[TR][TD][B]8 — Verify the artefact[/B][/TD][TD]Inspect architecture, dependencies, symbols and expected install path before replacing a system component.[/TD][/TR]
[TR][TD][B]9 — Integrate reversibly[/B][/TD][TD]Preserve the original component and record permissions, ownership, extended attributes and installation method.[/TD][/TR]
[TR][TD][B]10 — Runtime validation[/B][/TD][TD]Demonstrate that the target consumer loads the replacement and that the intended functionality actually works.[/TD][/TR]
[/TABLE]
A useful shorthand for this process is:
[CODE]
PROVENANCE
→ TARGET / FREEZE
→ DIFF
→ CLASSIFY
→ CONTRACT
→ IMPLEMENT
→ COMPILE
→ LINK / ARTEFACT VERIFY
→ INSTALL
→ BOOT
→ RUNTIME / SEMANTIC VALIDATE
Not every small application build requires this level of formality.
For operating-system reconstruction, however, it prevents several common false conclusions.
DO NOT PATCH BEFORE IDENTIFYING THE FAILURE LAYER
A failed source build can originate at several different layers.
Failure
Likely investigation
Bad CPU type in executable
A build-time tool is probably Intel-only. Determine the exact executable/path which was invoked.
Missing header
Public SDK deficiency, private/generated header dependency, wrong SDK or missing producer project.
Undefined symbol during linking
Missing library, incorrect source generation, incorrect export set or missing implementation.
Assembler rejects PPC source
Wrong assembler generation, incorrect architecture selection or source/tool incompatibility.
Linker rejects PPC object
Wrong ld64, unsupported relocation, architecture mismatch or incompatible object-generation behaviour.
Build succeeds but binary is Intel-only
Architecture variables or project targets did not propagate to the final product.
Binary launches but functionality fails
Runtime/API/ABI/semantic problem rather than merely a build problem.
Loader reports missing symbol
Installed dependency generation does not satisfy the binary’s import contract.
The correct response to:
Code:
Bad CPU type in executable
is therefore not automatically:
Code:
rebuild the project
but:
Code:
identify which executable failed
→ inspect its architecture
→ determine why that executable was selected
→ replace/rebuild only if required
CONTROL YOUR ENVIRONMENT
For reproducible work, record at minimum:
Code:
sw_vers
uname -a
echo “$PATH”
echo “$SDKROOT”
echo “$MACOSX_DEPLOYMENT_TARGET”
echo “$ARCHS”
echo “$RC_ARCHS”
which gcc
gcc –version
which as
as –version
which ld
ld -v
which make
make –version
Where appropriate also capture:
Code:
xcodebuild -version
xcodebuild -showsdks
and architecture information for every important tool:
Code:
file
lipo -info
A build result should ideally be reproducible from the recorded environment without depending upon undocumented modifications elsewhere on the machine.
CLEAN OUTPUT DIRECTORIES
Apple source projects commonly use:
Code:
SRCROOT
OBJROOT
SYMROOT
DSTROOT
and related XBS-style variables.
Where practical, create explicit clean output directories for each controlled attempt.
Then bind the project’s build variables to those locations.
This makes it much easier to distinguish:
[]compiler output;
[]intermediate objects;
[]debug/symbol products;
[]the final installation Root;
files inherited from an earlier build attempt.
When changing architecture, SDK, compiler, linker, dependency Roots or patches, perform a clean build unless the project’s build system explicitly guarantees the previous objects remain valid.
DARWINBUILD
DarwinBuild is Apple’s historical/open-source framework for reconstructing projects from the Darwin source releases.
DarwinBuild is especially relevant to SLPPC because it was designed to address exactly the sort of dependency problem encountered when rebuilding low-level Darwin components.
It can:
[]associate an OS build with exact project/source versions;
[]fetch source;
[]prepare isolated BuildRoots;
[]stage prerequisite Roots;
[]generate header-only builds;
[]record build logs;
[]record dependency access;
[]track files produced by individual projects.
A traditional DarwinBuild working directory contains:
Code:
.build
Headers
Logs
Roots
Sources
Symbols
The build framework also creates the standard:
Code:
SRCROOT
OBJROOT
SYMROOT
DSTROOT
environment required by many Apple projects.
Header-only builds
Low-level Darwin projects frequently contain circular dependencies.
DarwinBuild supports:
Code:
darwinbuild -headers
to generate and stage headers separately.
This is particularly useful with projects such as XNU, cctools, Libc and IOKitUser where one project may require generated/private headers from another before either complete binary product can be built.
Dependency logging
DarwinBuild also supports dependency logging so that files opened and executables invoked during a build can be recorded.
That provides useful evidence for determining:
Code:
which headers were actually consumed
which tools actually executed
which Roots were required
rather than reconstructing the dependency graph entirely from guesswork.
Important qualification:
DarwinBuild is not a one-command Snow Leopard PowerPC build system.
Historical build plists, default architectures, binary Roots, private dependencies and toolchain assumptions still have to be reconciled with the PPC target.
A DarwinBuild Root is the staged output of a successful project build.
Roots can contain:
[]runtime binaries;
[]libraries;
[]private/generated headers;
[]build tools;
[]static libraries;
[]intermediate products required by other projects.
This distinction matters because some files required to reconstruct Snow Leopard are build-time constituents rather than independently shipping system components.
For example, Apple projects can consume static libraries staged under locations such as:
Code:
/usr/local/lib/system
during construction of larger system libraries.
A file appearing in a DarwinBuild Root therefore does not automatically imply:
“this file shipped independently in /usr/lib on retail Snow Leopard.”
Root evidence and shipping-state evidence must remain distinct.
SOURCE VERSION SELECTION
Selecting the correct source generation is one of the most important parts of reconstructing an Apple component.
Do not use:
Code:
latest available source
as the default rule.
Instead establish:
Code:
target OS/build
→ expected component
→ producer project
→ project version associated with target
→ dependencies
Adjacent source releases are extremely useful for diffing.
They should not automatically be substituted into the target merely because they contain more code or a later version number.
SOURCE RELEASE ≠ SHIPPING BINARY
This distinction deserves explicit emphasis.
Apple releasing:
Code:
ProjectName-X.Y.Z
as part of a Snow Leopard source release establishes that Apple associated that source project with that release family.
It does not automatically prove:
[]which target Apple built from it;
[]which architecture slices were produced;
[]which build options were used;
[]whether every produced artefact shipped;
[]the exact installed file version;
[]the exact relationship between a published source archive and a retail-system binary.
When the question is:
“What did untouched 10A432 actually ship?”
the strongest evidence comes from the untouched installed system, installation packages, BOMs, manifests and binaries themselves.
Source publication and shipping-state evidence should corroborate one another rather than being silently treated as equivalent.
PRODUCER / CONSUMER ANALYSIS
For difficult operating-system components, document both sides of the dependency:
Code:
PRODUCER
Which source project/build creates this file?
CONSUMER
Which component actually needs or loads it?
This avoids replacing a file merely because its name resembles the missing dependency.
SYMBOLS: SOURCE EXISTENCE IS NOT ENOUGH
For low-level system work, distinguish:
Code:
function exists in source
↓
function compiled into object
↓
object included in final binary
↓
symbol retained in linked artefact
↓
symbol exported at required visibility
↓
consumer can resolve it
↓
runtime semantics are correct
Useful inspection tools include:
Code:
nm
otool
strings
lipo
file
For an undefined-symbol failure:
Code:
nm -u
can help identify the import.
Then inspect the expected provider:
Code:
nm
Where relevant, also verify whether the symbol is externally exported rather than merely present locally.
At the time of this Wiki review, the Snow Leopard procedure requires:
[]standard Xcode 3.2.6;
[]replacement Darwin assembler/linker tooling;
[]Apple make;
[]replacement bsdtar;
[]a modern bootstrap curl for current HTTPS;
[]the PPCPorts base under /opt/local.
For fuller development workloads, additional utilities including:
Code:
m4
bison
…
may also need replacement, including duplicate copies under:
Code:
/Developer/usr/bin
where individual builds invoke those directly.
Use the PowerPC Ports website for its current exact installation procedure.
Do not treat the copy in this Wiki as a permanently frozen PowerPC Ports instruction set.
POWERPC PORTS VS SLPPC
The projects are complementary but distinct.
SLPPC
PowerPC Ports / PPCPorts
Reconstructs and tests Snow Leopard itself.
Ports third-party/open-source software to PowerPC macOS.
Investigates XNU, frameworks, system services, KEXTs and Apple source projects.
Exercises the resulting operating system through large numbers of real software builds.
May reconstruct historical Apple developer tools for compatibility.
May use newer compilers/tooling where that is appropriate for modern software.
Targets historical OS correctness and compatibility.
Targets usable modern software on surviving PowerPC systems.
A PowerPC Ports workaround is useful SLPPC evidence.
It does not automatically become part of the SLPPC operating-system design.
Likewise, SLPPC component reconstruction may improve the environment available to PowerPC Ports without making the two projects one project.
CURRENT TOOLCHAIN RECONSTRUCTION WORK
The historical January 2025 minimum proved that a useful native environment could be assembled.
The next engineering task is to make that environment reproducibly characterised.
Current work is therefore centred on:
Stage
Objective
T1 — Recover installer artefacts
Recover the exact historical 2025 installer/package bytes where possible and record hashes, contents and architecture.
T2 — Capture stock counterparts
Inventory the corresponding tools installed by untouched Xcode 3.2.6 / Snow Leopard, including paths, versions and slices.
T3 — Replacement map
Determine exactly which stock tools are replaced, which project produces each replacement and which consumers require it.
T4 — Controlled reproduction
Reproduce a clean native PPC build using only the demonstrated minimum environment and document the result.
T5 — Consumer-driven expansion
Add gm4, bison and other tools only when a real consuming build demonstrates their necessity.
This prevents the development environment from becoming an undocumented collection of replacement binaries.
[]the first meaningful error rather than only the final make failure;
[]the complete command which produced it;
[]the architecture of the executable which failed;
[]relevant environment variables;
[]the exact source version;
[]any local patches;
whether the failure also occurs in a clean control environment.
Please do not remove failed experiments from the record solely because they did not produce a working binary.
A characterised failure can close an incorrect path and prevent substantial duplicated effort.
HIGH-VALUE DEVELOPER CONTRIBUTIONS
Area
Useful contribution
Toolchain archive recovery
Original copies of the historical Snow Leopard PPC developer-tool installers, with hashes and provenance.
Untouched Xcode 3.2.6 capture
Architecture/version inventory of stock command-line and /Developer tools before replacements.
DarwinBuild Roots
Original Snow Leopard-era Roots, particularly artefacts containing PPC slices.
Build recipes
Exact commands and environment needed to reproduce Apple source projects on PPC.
PPC assembly
Identify retained, removed or divergent PowerPC assembly implementations between Leopard and Snow Leopard source generations.
Endian auditing
Identify real big-endian defects with reproducible tests rather than speculative source changes.
Symbol analysis
Map missing imports to exact producer projects and determine whether required PPC implementations survive.
Build dependency reconstruction
Recover private/generated headers, static libraries, build-only tools and producer relationships.
Native PPC validation
Reproduce builds directly under Snow Leopard PowerPC using a documented toolchain.
It should not become another complete catalogue of every open-source component present in Mac OS X.
Individual Apple source projects should be included here when they:
[]produce a developer tool;
[]provide an important build dependency;
[]illustrate a reconstruction method;
[]are directly relevant to the current build environment.
Operating-system component status itself belongs primarily in Post #1.
The aim is not merely to make a compiler emit PowerPC code.
The aim is to build a reproducible development environment in which we can establish what was built, how it was built, what it replaced, and whether the resulting component actually works within Snow Leopard PowerPC.
The Snow Leopard thread, unlike other similarly sized threads, is borderline impossible to follow for someone that isn't involved.
I thought about the possibility of running SL on one of my Macs, but I don't even know what the state of it is, the OP is not a WikiPost, I just learned yesterday that there's two separate SL projects now? Not to mention the multiple pages per day of developing content.
Forget separate threads, it may be worth pushing for a subforum for it.
I think it's a good idea to have separate threads mostly because the current one is mostly focused on the betas and everything related to 10.6.8 gets buried in all those pages.
Would be nice to have the first few posts describing the current state, what works and what doesn't, download links, tested machines, as simple as possible so people outside the project can read and understand.
I think it's a good idea to have separate threads mostly because the current one is mostly focused on the betas and everything related to 10.6.8 gets buried in all those pages.
Would be nice to have the first few posts describing the current state, what works and what doesn't, download links, tested machines, as simple as possible so people outside the project can read and understand.
Yeah, I second this: while I don’t mind development stuff in the main thread, it is more convenient to have a dedicated thread, so we can focus on relevant things and messages do not get buried in generic discussions.
I think it's a good idea to have separate threads mostly because the current one is mostly focused on the betas and everything related to 10.6.8 gets buried in all those pages.
Would be nice to have the first few posts describing the current state, what works and what doesn't, download links, tested machines, as simple as possible so people outside the project can read and understand.
Since April 2020, efforts to get Snow Leopard working on PowerPC systems have been ongoing and documented in This thread. What started out initially as an effort to explore, document and update a number of the available Snow Leopard Developer Previews that, when patched, are able to boot on PowerPC systems has continued over the years. These modifications were relatively easy to follow.
We have now reached a stage where a working version of 10.6.8 is available, currently using 'donor parts' from Developer Build 10A190 and 10.5.8 Leopard. Further development requires a lot of 'developer talk' and low-level discussion that is less easy to comprehend and follow.
As this type of post has been objected to in the past, by some on the thread, the following question is being asked of the community...
Should continued work on 10.6.8 PowerPC and Xcode 3.2.X have its own dedicated thread?
I’ve been asking for this, explicitly, for only the last, like, three years.
I offer this thread ought to be upgraded to a wikipost for developer/development level stuff, particularly third-party ports, to be continued and expanded on over here.
The April 2020 thread came together for the getting the entire OS running (and stably). It was reconstructing what was being handled by Apple internally in 2008 and 2009, based on access to the earlier builds known to boot on PowerPC Macs. The goal for that thread was intended to address the end-user experience of testing and even using SL-PPC on their own PowerPC Macs. That thread must continue to be the place for exactly that and, where/as applicable, will refer to activity, fixes, and releases from collaborations and works from this specialized thread focussed on building elements from source and other lower-level, coding-level work. This work absolutely aids the entire OS, even as it isn’t the entirety of Snow Leopard as an OS.
I’ve been asking for this, explicitly, for only the last, like, three years.
I offer this thread ought to be upgraded to a wikipost for developer/development level stuff, particularly third-party ports, to be continued and expanded on over here.
The April 2020 thread came together for the getting the entire OS running (and stably). It was reconstructing what was being handled by Apple internally in 2008 and 2009, based on access to the earlier builds known to boot on PowerPC Macs. The goal for that thread was intended to address the end-user experience of testing and even using SL-PPC on their own PowerPC Macs. That thread must continue to be the place for exactly that and, where/as applicable, will refer to activity, fixes, and releases from collaborations and works from this specialized thread focussed on building elements from source and other lower-level, coding-level work. This work absolutely aids the entire OS, even as it isn’t the entirety of Snow Leopard as an OS.
From 2021, I was aware of how I’d be unable to successfully start another thread for development. (I urged others to go forward and do that, but I was dismissed.)
As with project drift/feature creep/whatever, it had strayed from the core remit of focussing, foremost, to get Snow Leopard running on as many PowerPC Macs, in the latest possible developer preview, as possible. Instead, it ended up becoming a place for third-party developer stuff which did little to, say, get a PowerPC Mac running a build stably enough to reach a Finder desktop. It always needed its own place.
So from that, I was aware it’d require another person, basically one of y’all, to do what you’ve done here with this new discussion wikipost thread for SL-PPC development. And now that day has arrived. It would have been better for it to have been struck into existence then, but better late than never.
Well the poll results demonstrate why i created the poll and this thread - we’re hovering around a 50/50 split of opinion on the matter @B S Magnet.
As for the original thread being derailed, that’s a subjective opinion. Even in the first month of the project we discussed that at some point paths would diverge into a 10A096 with Leopard components and a 10A190/10A222… with updated components. The original thread was never dedicated to either path in particular. It was a thread for SL_PPC as @Larsvonhier coined it.
Once you volunteered to be responsible for the WikiPost on that thread detailing all of the steps needed and which components from Leopard were required to tweak and improve 10A096, and then gave the project a nickname ‘Clouded Leopard’ it started to become clear that there was no longer space for both paths in one thread, particularly as your focus was solely on 10A096. This was compounded with MacPorts related posts entering the fray with @kencu followed by @barracuda156.
The three of us discussed divergence and agreed that MacPorts needed its own thread and that it wasn’t a fundamental part of the OS, even if third party software compatibility had been discussed from the get go, but also that the three of us, as the only active, consistent testers and contributors working on SL_PPC systems for a long period of time had become an ‘adhoc team’ and that sharing findings together remained the best course of action.
We then took a respite. I continued to quietly compile and tinker off thread when I found the time, @barracuda156 continued to share MacPorts on 10A190 progress in his own threads (admittedly sometimes in the wrong thread) and @educovas appeared with a 10A222 build and was working on a 10A432 build using components from 10A190.
Excitement ensued. People became active and vocal again, and then demands and disagreements emerged.
The consensus is not clear but the objections to technical posts being posted on that thread and its confusing nature for newcomers is clearly an issue, made clear by multiple users now. The fact that it has always been a technical thread is irrelevant at this point - it is no longer easy to follow for the whole of the community.
@educovas left that original thread and continued to work with a select group of people, testing and putting together a 10.6.8 build which was then shared on that thread for posterity. The build was apparently tested on multiple systems and by multiple people and was done outside of the scope of that project. This build has been volunteered to the community ‘as is’.
This brings us back to the poll and this thread.
I’m happy to go in either direction, but i will continue on the same path that was outlined in my first post in 2020 - building and testing system components from AOSP with a view to patching a build (now 10.6.8) to be as close to the retail version as possible.
If the community would like development in this thread only then we will encourage all development discussions related to the OS itself to be posted here and provide a comprehensive wiki, toolkit and references.
It is a community decision and the outcome will be respected.
What I can gather is this has been stewing out of sight, as I haven’t posted anything in many months about the direction and scope of the project — not since someone new came in, claimed they got a remarkable thing to work, but then declined to document how they did it. Yah, that didn’t sit right with me, I said as much, and I left it at that. I’ll expand on that a bit below.
After that, I went on to focus on other Mac (and life and work) things. That was several months ago, and this new thread is, well, new now.
As for the original thread being derailed, that’s a subjective opinion. Even in the first month of the project we discussed that at some point paths would diverge into a 10A096 with Leopard components and a 10A190/10A222… with updated components. The original thread was never dedicated to either path in particular. It was a thread for SL_PPC as @Larsvonhier coined it.
Once you volunteered to be responsible for the WikiPost on that thread detailing all of the steps needed and which components from Leopard were required to tweak and improve 10A096, and then gave the project a nickname ‘Clouded Leopard’ it started to become clear that there was no longer space for both paths in one thread, particularly as your focus was solely on 10A096. This was compounded with MacPorts related posts entering the fray with @kencu followed by @barracuda156.
My focus being on 10A96 was not a distraction from folks testing and updating the wikipost for 10A190, and I repeated this regularly, noting I was the oddball working with 10A96 and wasn‘t offended by being alone with that. I wanted — hoped — folks would do the same with 10A190 as I had done with 10A96.
I continued adding new information related to 10A96, such as in Table 4, because that was what I was working on. I was not in a place or position to do the same for 10A190, but many others were.
I took up the voluntary mantle of maintaining the wikipost’s format and readability because no one else stepped up to do so. What was there back in 2020 was quickly devolving into a poorly edited wiki which so often undermines the utility of other, complex, lengthy wikiposts found elsewhere on MR (most notably, by folks whose professional backgrounds probably aren’t adjacent to or are in technical writing/documentation).
I didn’t fault anyone for not contributing to the testing of 10A190 and not updating the 10A190 column for verified functionality. It would have been nice for someone to be doing what I was doing on the 10A190 side, but that didn’t happen.
I don’t think it is OK to fault me on behalf of others who chose not to do that component/QA testing work on 10A190, to update folks in the ongoing discussion or in the wikipost on those component swaps.
Even as many others were trying out 10A190 on their gear (totally OK by me, always), I didn’t press others to step up to do the same for 10A190 or even later builds as I had been doing for 10A96. The column in Table 4was already there, waiting for someone working on 10A190 to fill it in. The occasional post notwithstanding, particularly throughout 2020, that generally did not happen.
But — and this is key — I have always expected a level of quality, transparency, and clarity with communication to make sure documentation for what had been tested was available and accessible to all, and in a human-readable presentation/format. That no one took up that mantle with 10A190 or reported on swapped components which worked (or didn’t) is on those who worked on 10A190.
I’m sorry. Your grievance here is unfair. And a great deal of what you’ve brought up above isn’t even central to to the Snow Leopard itself.
That was the remit, after all: a PowerPC Mac owner who wants to install, try out, and even run Snow Leopard on their PowerPC Mac. They want it to work, and if it works, to find ways to make the OS work better (i.e., fewer crashes, bugs, getting AirPort to play nice, etc.).
Macports? Respectfully, that should have always been spun off to another thread about — wait for it — Macports on an unsupported OS back in late 2021. It originally came up in 2020 while folks were still trying out third-party software to see which ones worked and which did not.
The three of us discussed divergence and agreed that MacPorts needed its own thread and that it wasn’t a fundamental part of the OS, even if third party software compatibility had been discussed from the get go, but also that the three of us, as the only active, consistent testers and contributors working on SL_PPC systems for a long period of time had become an ‘adhoc team’ and that sharing findings together remained the best course of action.
With candour, what wore me out — burnt me out — from continuing beyond mid-2022 was the steady abundance of Macports-related posts being nearly all of my alerts whenever a new post on SL-PPC came up.
It got to a point when I was, like, “What even is this anymore?”
From the remit of all the things central to making Snow Leopard run smoothly for the way most folks use OS X, each “Oh, this is about Macports again” became a distraction. Less wheat, more chaff. But by then, my expressed suggestion, to spin off non-Snow Leopard stuff over to another thread, was rebuffed by the very party generating the content which was ancillary to the remit of getting SL to run on PowerPC Macs. [!]
The work they did was and is laudable, and — this is key — it always belonged in its own topical place. I couldn’t twist their arm to go open a new thread on Macports in the Darwin 10.0.0dX environment. I found this frustrating, but really: what more could I do?
So… more drift away from the project’s central remit on the SL-PPC thread continued apace, and I reached a point, like around June 2022, when I was just, “OK, I can’t with this anymore.” Moreoever, few contributions to areas in the wikipost reserved for 10A190 had been added by anyone to in quite some time, despite most user activity on the thread being focussed on 10A190/10.0.0d2 matters. 🤷♀️
We then took a respite. I continued to quietly compile and tinker off thread when I found the time, @barracuda156 continued to share MacPorts on 10A190 progress in his own threads (admittedly sometimes in the wrong thread) and @educovas appeared with a 10A222 build and was working on a 10A432 build using components from 10A190.
Excitement ensued. People became active and vocal again, and then demands and disagreements emerged.
The consensus is not clear but the objections to technical posts being posted on that thread and its confusing nature for newcomers is clearly an issue, made clear by multiple users now. The fact that it has always been a technical thread is irrelevant at this point - it is no longer easy to follow for the whole of the community.
It’s no longer easy to follow for the reason I just raised: the Macports stuff always belonged with another thread germane to the third-party Macports project, to keep the original remit of the SL-PPC thread focussed on Snow Leopard itself.
To newcomers, the thread, particularly from 2022, appeared preoccupied not so much with Snow Leopard, but with Macports. Feature creep? Project drift? Whatever. It happened.
@educovas left that original thread and continued to work with a select group of people, testing and putting together a 10.6.8 build which was then shared on that thread for posterity. The build was apparently tested on multiple systems and by multiple people and was done outside of the scope of that project. This build has been volunteered to the community ‘as is’.
I was clear from the outset on the need for transparency and clear communication, in order for others to be able to repeat what he asserted he had accomplished. (I certainly wanted to repeat what he did, and for a minute, I thought I might get much more involved again.) This is the bedrock and cornerstone of good (scientific) method and peer review. Software engineering is still science.
He wasn‘t interested in that, and so he left.
Unlike others, I wasn’t so much dazzled by his breakthroughs as I was sceptical, so long as there wasn’t a way for anyone else to replicate, openly, what he was doing. This isn’t to argue any of it was fabiricated, but we needed (and, frankly, deserved) a way for other folks to walk through how he did it by having the ability to replicate it ourselves. A black box tack wasn’t it.
And yes, I’m kind of a stickler for openness over proprietary behaviour. As humans, we work at our very best when we share and collaborate together, not when we withhold and compete against one another.
I’m happy to go in either direction, but i will continue on the same path that was outlined in my first post in 2020 - building and testing system components from AOSP with a view to patching a build (now 10.6.8) to be as close to the retail version as possible.
Cool, and I’m glad you’re doing that and that that’s still your area of focus and interest. I hope I haven’t gotten in your way of that.
Also bear in mind, from the vantage of others, the AOSP work you were doing seemed to set about getting, say, something like Build 10A222 to boot fully and pull up a working Finder and WindowServer on a PowerPC box. Or, in the case of 10A190 elements, like frameworks or kexts, which were broken for PowerPC, compiling from the AOSP source might mend those broken bits.
And now, with some hindsight, I’m under the impression it wasn’t so much about that than it was to build AOSP elements for PowerPC operability in a Darwin 10.0.0dX environment, without specific attention to make a broken bits in particular build, like 10A190 or 10A222, to work better. Please correct me on that.
If the community would like development in this thread only then we will encourage all development discussions related to the OS itself to be posted here and provide a comprehensive wiki, toolkit and references.
"Snow Leopard on Unsupported PowerPC Macs”, per the original post before it became a wiki, didn’t set out to be a thread about software development or building toolchains. It certainly didn’t bring up a third-party repo. But that’s where it went nevertheless. It was about getting Snow Leopard to boot up and to run on a PowerPC Mac.
It seemed a clear remit: “10A190? Yes, mostly. 10A96? Yes, but very early. 10A222? WindowServer and Finder aren’t happy.”
I… I just find it curious how you’ve gone forward right now with this thread/poll/wikipost, unprompted, even as — by shared measures — you don’t favour creating a thread like this in the first place. It reads to me as slightly hostile, even if that isn’t the intent. This line alone comes across as very, “Sir, yes sir” as the only valid response, and it’s a line I couldn’t have said (something-something-about-gendered-allowances-etc.)
I also find it curious this is coming up right now and not, say, quite some time ago, back when I was still heavily involved with getting Snow Leopard running smoothly on PowerPC Macs. And although I’m not going to take this personally, I do gather the tenor of your comments here — including the lol emoji — feel awfully personal by nature. (Or maybe that’s a total misread, idk.) If you have had a grievance with me, there’s been nothing here which couldn’t have been brought up with direct, person-to-person communiction (i.e., pm).
Anyhow, I’m not actively involved in the main project and I haven’t been for a while. It’s never meant I lost interest, but I did grow tired for the aforementioned reasons of project drift/creep. I would like to return to it again (because I like using Snow Leopard as a “regular driver” on my fastest available PPC Mac). And when I do so, my focus will resume on the basic remit laid out in the original post by Lars and early replies by vddrnnr.
But if you take umbrage with me as a person, then this is not the place for it.
p.s., The poll’s data would be more effective with checkboxes, not radio buttons.
What I can gather is this has been stewing out of sight, as I haven’t posted anything in many months about the direction and scope of the project — not since someone new came in, claimed they got a remarkable thing to work, but then declined to document how they did it. Yah, that didn’t sit right with me, I said as much, and I left it at that. I’ll expand on that a bit below.
After that, I went on to focus on other Mac (and life and work) things. That was several months ago, and this new thread is, well, new now.
OK.
My focus being on 10A96 was not a distraction from folks testing and updating the wikipost for 10A190, and I repeated this regularly, noting I was the oddball working with 10A96 and wasn‘t offended by being alone with that. I wanted — hoped — folks would do the same with 10A190 as I had done with 10A96.
I continued adding new information related to 10A96, such as in Table 4, because that was what I was working on. I was not in a place or position to do the same for 10A190, but many others were.
I took up the voluntary mantle of maintaining the wikipost’s format and readability because no one else stepped up to do so. What was there back in 2020 was quickly devolving into a poorly edited wiki which so often undermines the utility of other, complex, lengthy wikiposts found elsewhere on MR (most notably, by folks whose professional backgrounds probably aren’t adjacent to or are in technical writing/documentation).
I didn’t fault anyone for not contributing to the testing of 10A190 and not updating the 10A190 column for verified functionality. It would have been nice for someone to be doing what I was doing on the 10A190 side, but that didn’t happen.
I don’t think it is OK to fault me on behalf of others who chose not to do that component/QA testing work on 10A190, to update folks in the ongoing discussion or in the wikipost on those component swaps.
Even as many others were trying out 10A190 on their gear (totally OK by me, always), I didn’t press others to step up to do the same for 10A190 or even later builds as I had been doing for 10A96. The column in Table 4was already there, waiting for someone working on 10A190 to fill it in. The occasional post notwithstanding, particularly throughout 2020, that generally did not happen.
But — and this is key — I have always expected a level of quality, transparency, and clarity with communication to make sure documentation for what had been tested was available and accessible to all, and in a human-readable presentation/format. That no one took up that mantle with 10A190 or reported on swapped components which worked (or didn’t) is on those who worked on 10A190.
I’m sorry. Your grievance here is unfair. And a great deal of what you’ve brought up above isn’t even central to to the Snow Leopard itself.
That was the remit, after all: a PowerPC Mac owner who wants to install, try out, and even run Snow Leopard on their PowerPC Mac. They want it to work, and if it works, to find ways to make the OS work better (i.e., fewer crashes, bugs, getting AirPort to play nice, etc.).
Macports? Respectfully, that should have always been spun off to another thread about — wait for it — Macports on an unsupported OS back in late 2021. It originally came up in 2020 while folks were still trying out third-party software to see which ones worked and which did not.
With candour, what wore me out — burnt me out — from continuing beyond mid-2022 was the steady abundance of Macports-related posts being nearly all of my alerts whenever a new post on SL-PPC came up.
It got to a point when I was, like, “What even is this anymore?”
From the remit of all the things central to making Snow Leopard run smoothly for the way most folks use OS X, each “Oh, this is about Macports again” became a distraction. Less wheat, more chaff. But by then, my expressed suggestion, to spin off non-Snow Leopard stuff over to another thread, was rebuffed by the very party generating the content which was ancillary to the remit of getting SL to run on PowerPC Macs. [!]
The work they did was and is laudable, and — this is key — it always belonged in its own topical place. I couldn’t twist their arm to go open a new thread on Macports in the Darwin 10.0.0dX environment. I found this frustrating, but really: what more could I do?
So… more drift away from the project’s central remit on the SL-PPC thread continued apace, and I reached a point, like around June 2022, when I was just, “OK, I can’t with this anymore.” Moreoever, few contributions to areas in the wikipost reserved for 10A190 had been added by anyone to in quite some time, despite most user activity on the thread being focussed on 10A190/10.0.0d2 matters. 🤷♀️
It’s no longer easy to follow for the reason I just raised: the Macports stuff always belonged with another thread germane to the third-party Macports project, to keep the original remit of the SL-PPC thread focussed on Snow Leopard itself.
To newcomers, the thread, particularly from 2022, appeared preoccupied not so much with Snow Leopard, but with Macports. Feature creep? Project drift? Whatever. It happened.
Good on him!
I was clear from the outset on the need for transparency and clear communication, in order for others to be able to repeat what he asserted he had accomplished. (I certainly wanted to repeat what he did, and for a minute, I thought I might get much more involved again.) This is the bedrock and cornerstone of good (scientific) method and peer review. Software engineering is still science.
He wasn‘t interested in that, and so he left.
Unlike others, I wasn’t so much dazzled by his breakthroughs as I was sceptical, so long as there wasn’t a way for anyone else to replicate, openly, what he was doing. This isn’t to argue any of it was fabiricated, but we needed (and, frankly, deserved) a way for other folks to walk through how he did it by having the ability to replicate it ourselves. A black box tack wasn’t it.
And yes, I’m kind of a stickler for openness over proprietary behaviour. As humans, we work at our very best when we share and collaborate together, not when we withhold and compete against one another.
Cool, and I’m glad you’re doing that and that that’s still your area of focus and interest. I hope I haven’t gotten in your way of that.
Also bear in mind, from the vantage of others, the AOSP work you were doing seemed to set about getting, say, something like Build 10A222 to boot fully and pull up a working Finder and WindowServer on a PowerPC box. Or, in the case of 10A190 elements, like frameworks or kexts, which were broken for PowerPC, compiling from the AOSP source might mend those broken bits.
And now, with some hindsight, I’m under the impression it wasn’t so much about that than it was to build AOSP elements for PowerPC operability in a Darwin 10.0.0dX environment, without specific attention to make a broken bits in particular build, like 10A190 or 10A222, to work better. Please correct me on that.
Here’s the thing:
"Snow Leopard on Unsupported PowerPC Macs”, per the original post before it became a wiki, didn’t set out to be a thread about software development or building toolchains. It certainly didn’t bring up a third-party repo. But that’s where it went nevertheless. It was about getting Snow Leopard to boot up and to run on a PowerPC Mac.
It seemed a clear remit: “10A190? Yes, mostly. 10A96? Yes, but very early. 10A222? WindowServer and Finder aren’t happy.”
I… I just find it curious how you’ve gone forward right now with this thread/poll/wikipost, unprompted, even as — by shared measures — you don’t favour creating a thread like this in the first place. It reads to me as slightly hostile, even if that isn’t the intent. This line alone comes across as very, “Sir, yes sir” as the only valid response, and it’s a line I couldn’t have said (something-something-about-gendered-allowances-etc.)
I also find it curious this is coming up right now and not, say, quite some time ago, back when I was still heavily involved with getting Snow Leopard running smoothly on PowerPC Macs. And although I’m not going to take this personally, I do gather the tenor of your comments here — including the lol emoji — feel awfully personal by nature. (Or maybe that’s a total misread, idk.) If you have had a grievance with me, there’s been nothing here which couldn’t have been brought up with direct, person-to-person communiction (i.e., pm).
Anyhow, I’m not actively involved in the main project and I haven’t been for a while. It’s never meant I lost interest, but I did grow tired for the aforementioned reasons of project drift/creep. I would like to return to it again (because I like using Snow Leopard as a “regular driver” on my fastest available PPC Mac). And when I do so, my focus will resume on the basic remit laid out in the original post by Lars and early replies by vddrnnr.
But if you take umbrage with me as a person, then this is not the place for it.
p.s., The poll’s data would be more effective with checkboxes, not radio buttons.
Could we please keep at least some thread free from endless complaints that someone did something which has not matched with someone else’s expectations and views of what is “correct”?
MacPorts kept being brought up for a simple reason: there is no alternative. It would be awesome if someone did make a different and better build system. That did not happen so far, so MacPorts remains de facto the only way to make old macOS somewhat usable beyond booting it and running TenFourFox. (Potentially NetBSD’s pkgsrc can be a replacement, it will be very much welcome if someone works on it.)
This thread is not about MacPorts however, so why is this even being brought up? The only utility MacPorts may have for the OS development is setting up reproducible builds of system components. System components should not be built with MacPorts-supplied (or any third-party) Unix tools and should not depend on anything within MacPorts (or any other package management system). MacPorts has a great value for using SL PPC, but not for developing for the OS itself.
Could we please keep at least some thread free from endless complaints that someone did something which has not matched with someone else’s expectations and views of what is “correct”?
MacPorts kept being brought up for a simple reason: there is no alternative. It would be awesome if someone did make a different and better build system. That did not happen so far, so MacPorts remains de facto the only way to make old macOS somewhat usable beyond booting it and running TenFourFox. (Potentially NetBSD’s pkgsrc can be a replacement, it will be very much welcome if someone works on it.)
This thread is not about MacPorts however, so why is this even being brought up? The only utility MacPorts may have for the OS development is setting up reproducible builds of system components. System components should not be built with MacPorts-supplied (or any third-party) Unix tools and should not depend on anything within MacPorts (or any other package management system). MacPorts has a great value for using SL PPC, but not for developing for the OS itself.
Having a ready-to-go image that takes up at the point of registering user(s) is imho a good idea. Thought about that from the beginning. Downside is that some people do not trust such a pre-install due to what might be included there.
And we´ll have to update it from time to time with updated components that we find...
I prepared a list with newer kexts that exist in 10.5.8 in comparison to 10A96 and that run here - as 10.5.8 was clearly more serviced and a bit more recent than the initial 10.6 release(s). Will put it in a table on page #1 and attach a zip archive with all of them. Care has to be taken to test all modifications on various machines - as I found i.e. that ATA kext families seemed to work at first and then on another machine failed to recognize drives.
Good news: At least the newer iTunes 8.2.1 runs out-of-the box while the latest 10.5.8 version seems to need some updated frameworks.
Also tbd: A table with PPC applications that have been tested on 10.6 PPC, also on the wiki page #1 for everybody to submit what you found! I can start it in the evening...
Speaking of frameworks: That will be my next focus (and due to gigantic combinations and dependencies I will need all help I can get there! ;-). So the task would be to find 10.5.8 frameworks and libraries that run on 10.6 and improve things (as a basis for newer applications that req. them).
Somewhere in the system is also the reason for the faulty jpg decoding (that TenFourFox and Preview show). Interesting that other browsers handle it differently.
Might also be some framework stuff.
Having XCode 3.2 is great news, perhaps even the last for SL (3.2.6) will run?
But what can be done instead:
- run slightly more recent PPC apps (in comparison to 10.5.8)
- re-compile apps for 10.6 PPC with XCode 3.2.x (i.e. TenFourFox, atm without Altivec, but for G4/G5)
- and, as you said, use a more modern OS X
Some more findings:
10A190 (client) has Kernel 10.0.0d2 instead of earlier d1.
10A190 on my G5 has peculiar cyclic crash of dashboard after widgets called up one time. No problem if widgets are not summoned... that was never the case on any machine with 10A96 (server).
10A222 ! still partly boots into the installer with the BootX transplanted and the OSInstall.mpkg for clients. Finds some kexts, can´t find or load others, then stalls with "still waiting for root volume". Kernel is 10.0.0d3. But seems promising in comparison to later builds that cannot pre-load kexts into RAM before starting the kernel.
edit:
Brute-force copying all A190 kexts to the installer of A222 makes things worse, but still starts booting. Seems to be the game of finding the right match. Hopeful!
Depends on how you define the "final build". Most fundamental would imho be the kernel itself, so we´d either have it compiled from sources for PPC or find the "last" one with PPC support. Kexts are more or less explored now, but frameworks are to be checked. There are still some severe bugs in our 10A190 combo that might only be resolved by finding suitable frameworks from either later builds (again, PPC support needed) or from 10.5.8 wherever possible due to dependencies...
But it´s "just a lot of work", I guess.
I’ve been following this for a couple weeks now and decided to sign-up so i can more actively contribute. Currently running the dmg imaged onto a Powermac G5 Dual 2.3ghz with 4gb ram and the stock 6600. Experience is as expected and in line with previous PowerMac11,2 reports.
Thanks to all that have contributed thus far - this is an awesome project and one i never thought we would see come to life!
I Have downloaded iso’s for 10a096 server, 10a190, 10a222, 10a261 and 10a380. I also own a physical copy of retail server. I’m currently playing around with parts of each to see what if anything can be copied across to the more stable version of 10a190.
If i have the opportunity, assuming nobody more experienced has already started, i might try and compile from some open source files for 10.6-10.6.8 provided by Apple.
Testing thus far has consisted of attempting to implement suggestions from this thread, trying to install from my library of leopard apps for compatibility and attempting to ‘frankenmac’ using Pacifist, BatChmod and the various different installation iso’s.
Out of interest, has anybody managed to get software update working? I noticed after playing around with the LeopardWebkit instructions earlier in the thread that software update activated on one occasion - it may have been due to updating the security certificates or replacing some files. I haven’t installed anything from software update ti avoid x86 code overwriting my install.
Me joining the thread having been following along since the beginning at home for the first couple of weeks as a non-forum participant and discussing my intentions
1. There is a skin package tool that combines the look of Mountain Lion with Leopard, and that´s already called "Mountain Leopard" (also "Snow Leopard rebirth" would be ruled out for a similar reason ;-)
1.5 I do not really see a need for a new name. It´s still a Snow Leopard, running on PPC, or short SL_PPC.
In universal macOS times, we also did not differentiate between Tiger, PPC and Tiger, intel for example.
Classifying it as "hybrid" is imho not doing it a favour either. Do we call Catalina or Mojave on unsupported machines "hybrid" just because parts of earlier OS had to be taken and included to make them run...?
(Just my 2ct.)
Ok, thanks. I thought so but wanted to be sure. As said, this effect of not pre-loading the kexts starts from a certain dev build on, not just from 10.6.0 (which means, if solved, we could get a 10.6.0 final release running). Not sure if it´s solely Kernel-related, perhaps our BootX needs a re-compile of some sort, too. Your Ryan-Rempel doc offers really a good insight there..
…My gut feeling tells me that the road might split at some point: Pimping the A96 with older components (from 10.5.8) and finding/compiling newer ingredients for A190/A222 upwards.
I can confirm that compiling from the Open-source Apple code does indeed add/restore functionality in these developer builds. I’ve just compiled and installed the version of cups from 10.6.0 on 10A190 and it’s working - my printer panel now gracefully opens instead of crashing system preferences! I’m optimistic moving forward.
What I can gather is this has been stewing out of sight, as I haven’t posted anything in many months about the direction and scope of the project — not since someone new came in, claimed they got a remarkable thing to work, but then declined to document how they did it. Yah, that didn’t sit right with me, I said as much, and I left it at that. I’ll expand on that a bit below.
After that, I went on to focus on other Mac (and life and work) things. That was several months ago, and this new thread is, well, new now.
Nothing has been 'stewing' on my end, this poll/thread is merely an appropriate response to a recent surge of 'developer' focused posts on the main thread, being cognisant that there were complaints the last time that happened.
Yes it was made clear that it didn't sit right with you, and you're perfectly entitled to that opinion but it is only one opinion on a community thread and others were not offended by the same. The poll is a means to find out how everybody else feels about it.
My focus being on 10A96 was not a distraction from folks testing and updating the wikipost for 10A190, and I repeated this regularly, noting I was the oddball working with 10A96 and wasn‘t offended by being alone with that. I wanted — hoped — folks would do the same with 10A190 as I had done with 10A96.
I continued adding new information related to 10A96, such as in Table 4, because that was what I was working on. I was not in a place or position to do the same for 10A190, but many others were.
Your 10A096 work has never been a distraction. If someone wants to test all Leopard components and update the table then they are more than welcome and able to do so, it is a wikipost after all, this isn't the approach i've been taking as my goal has always been to update the most 'current' working version of SL_PPC with AOSP components built from source and/or with PowerPC components from retail 10.6.X. Different approaches, both in line with the original intent of the thread.
I took up the voluntary mantle of maintaining the wikipost’s format and readability because no one else stepped up to do so. What was there back in 2020 was quickly devolving into a poorly edited wiki which so often undermines the utility of other, complex, lengthy wikiposts found elsewhere on MR (most notably, by folks whose professional backgrounds probably aren’t adjacent to or are in technical writing/documentation).
I didn’t fault anyone for not contributing to the testing of 10A190 and not updating the 10A190 column for verified functionality. It would have been nice for someone to be doing what I was doing on the 10A190 side, but that didn’t happen.
I don’t think it is OK to fault me on behalf of others who chose not to do that component/QA testing work on 10A190, to update folks in the ongoing discussion or in the wikipost on those component swaps.
Even as many others were trying out 10A190 on their gear (totally OK by me, always), I didn’t press others to step up to do the same for 10A190 or even later builds as I had been doing for 10A96. The column in Table 4was already there, waiting for someone working on 10A190 to fill it in. The occasional post notwithstanding, particularly throughout 2020, that generally did not happen.
But — and this is key — I have always expected a level of quality, transparency, and clarity with communication to make sure documentation for what had been tested was available and accessible to all, and in a human-readable presentation/format. That no one took up that mantle with 10A190 or reported on swapped components which worked (or didn’t) is on those who worked on 10A190.
This i believe is the crux. The people working on 10A190/10A222 and beyond, were not following the same process of 'swap, test, report and record'. This is not because there is an agenda to keep the process opaque and mysterious but because the process of replacing unix level components is complex and the reporting of said changes is verbose with literally hundreds to thousands of files being swapped and changed in an ongoing manner, and no 'final conclusion' has been reached enough to record and document a 'step-by-step' for others to follow and repeat...yet. Marathon not a sprint, right? Instead there was an ongoing dialogue and discussion in the form of posts on the thread.
I don't have a grievance, please explain what i've said that you feel is unfair and irrelevant as i'm not sure what you're referring to here? Certainly was not my intention to offend you.
That was the remit, after all: a PowerPC Mac owner who wants to install, try out, and even run Snow Leopard on their PowerPC Mac. They want it to work, and if it works, to find ways to make the OS work better (i.e., fewer crashes, bugs, getting AirPort to play nice, etc.).
I don't see the point of contention or divergence here? We are just approaching the problem from a different vantage. You have been focussed on 'perfecting' the 10A096 experience and documented for whomever else may wish to repeat those steps, others like myself and @educovas are trying to get more recent Snow Leopard components and systems to run. All are efforts to run Snow Leopard on PowerPC...I don't see how they can be interpreted as anything other.
Macports? Respectfully, that should have always been spun off to another thread about — wait for it — Macports on an unsupported OS back in late 2021. It originally came up in 2020 while folks were still trying out third-party software to see which ones worked and which did not.
With candour, what wore me out — burnt me out — from continuing beyond mid-2022 was the steady abundance of Macports-related posts being nearly all of my alerts whenever a new post on SL-PPC came up.
It got to a point when I was, like, “What even is this anymore?”
From the remit of all the things central to making Snow Leopard run smoothly for the way most folks use OS X, each “Oh, this is about Macports again” became a distraction. Less wheat, more chaff. But by then, my expressed suggestion, to spin off non-Snow Leopard stuff over to another thread, was rebuffed by the very party generating the content which was ancillary to the remit of getting SL to run on PowerPC Macs. [!]
The work they did was and is laudable, and — this is key — it always belonged in its own topical place. I couldn’t twist their arm to go open a new thread on Macports in the Darwin 10.0.0dX environment. I found this frustrating, but really: what more could I do?
So… more drift away from the project’s central remit on the SL-PPC thread continued apace, and I reached a point, like around June 2022, when I was just, “OK, I can’t with this anymore.” Moreoever, few contributions to areas in the wikipost reserved for 10A190 had been added by anyone to in quite some time, despite most user activity on the thread being focussed on 10A190/10.0.0d2 matters. 🤷♀️
It’s no longer easy to follow for the reason I just raised: the Macports stuff always belonged with another thread germane to the third-party Macports project, to keep the original remit of the SL-PPC thread focussed on Snow Leopard itself.
To newcomers, the thread, particularly from 2022, appeared preoccupied not so much with Snow Leopard, but with Macports. Feature creep? Project drift? Whatever. It happened.
We did discuss this between us on that thread and i believe that the majority of MacPorts related discussion now lives on the appropriate threads. I do feel however that had other SL_PPC users, myself included, been more active on the thread when these posts were forming a chain of notifications, that they would have been 'diluted'. It's also fair to point out that as @barracuda156 continued to work on MacPorts for 10A190 and Rosetta 10.6.8, that they were becoming intimately familiar with those systems under the hood and were sharing useful findings as well that are relevant to SL_PPC. There are many examples of third party software discussion on that thread including MacPorts and Xcode discussion from very early in the timeline, so to chastise somebody for continuing this trend and not sticking to the main topic isn't really fair. We did agree, collectively, that moving forward only relevant posts would be made and as far as i'm aware that has been the case.
I was clear from the outset on the need for transparency and clear communication, in order for others to be able to repeat what he asserted he had accomplished. (I certainly wanted to repeat what he did, and for a minute, I thought I might get much more involved again.) This is the bedrock and cornerstone of good (scientific) method and peer review. Software engineering is still science.
He wasn‘t interested in that, and so he left.
Unlike others, I wasn’t so much dazzled by his breakthroughs as I was sceptical, so long as there wasn’t a way for anyone else to replicate, openly, what he was doing. This isn’t to argue any of it was fabiricated, but we needed (and, frankly, deserved) a way for other folks to walk through how he did it by having the ability to replicate it ourselves. A black box tack wasn’t it.
And yes, I’m kind of a stickler for openness over proprietary behaviour. As humans, we work at our very best when we share and collaborate together, not when we withhold and compete against one another.
Yes. You have been very clear. I think you may wish to consider this from another perspective; not all followers of the thread want to get their hands dirty and do it themselves, or spend hours writing or reading documentation, many simply want to be provided with a way to install Snow Leopard on their beloved PowerPC systems. @educovas has provided the community with working 10A222 and 10.6.8 images so that this is possible. I would like to know exactly what was done to accomplish both but I also understand that i'm not owed that explanation and that the task was completed without thorough note-taking. There is nothing to stop another person from taking the images apart, and analysing them much as has been done with the developer previews, and maybe someone might do that someday.
I don't see anybody competing, with the exception only exception being 'who gets to post what on the thread'.
Cool, and I’m glad you’re doing that and that that’s still your area of focus and interest. I hope I haven’t gotten in your way of that.
Also bear in mind, from the vantage of others, the AOSP work you were doing seemed to set about getting, say, something like Build 10A222 to boot fully and pull up a working Finder and WindowServer on a PowerPC box. Or, in the case of 10A190 elements, like frameworks or kexts, which were broken for PowerPC, compiling from the AOSP source might mend those broken bits.
And now, with some hindsight, I’m under the impression it wasn’t so much about that than it was to build AOSP elements for PowerPC operability in a Darwin 10.0.0dX environment, without specific attention to make a broken bits in particular build, like 10A190 or 10A222, to work better. Please correct me on that.
That's good because from my perspective, all Xcode/command line/unix level/technobabble is being shunned from the other thread because it is difficult to read and follow, but no you haven't gotten in my way.
Your impression is incorrect, I continue to work on 10A190 and intend to upload a final version when one exists just as i'd hope you will do for 10A096, so others can 'play' with them. My main focus however is to take whichever is the most recent bootable Snow Leopard image (was 10A190 then 10A222 and now 10.6.8) and apply the same AOSP component replacements with a view to help create the most up-to-date, as close as possible to retail version of Snow Leopard for us all to enjoy.
With my time being as limited as it is i can see why that might be unclear so i hope that this illuminates my position. I have no interest in building AOSP for the sake or building them not creating my own Darwin based OS...though that might be fun in the future.
"Snow Leopard on Unsupported PowerPC Macs”, per the original post before it became a wiki, didn’t set out to be a thread about software development or building toolchains. It certainly didn’t bring up a third-party repo. But that’s where it went nevertheless. It was about getting Snow Leopard to boot up and to run on a PowerPC Mac.
It seemed a clear remit: “10A190? Yes, mostly. 10A96? Yes, but very early. 10A222? WindowServer and Finder aren’t happy.”
The title and aim of that thread is 'Snow Leopard on Unsupported Macs'. Not Developer previews only on PowerPC macs. It was a thread started with the discovery that some DPs with tweaks could be booted and progressed to a community effort to explore how far we could go with 'Snow Leopard' on PowerPC. I see no major deviance from that remit, apart from what we have already discussed and addressed. Please correct me if i'm missing something?
I… I just find it curious how you’ve gone forward right now with this thread/poll/wikipost, unprompted, even as — by shared measures — you don’t favour creating a thread like this in the first place. It reads to me as slightly hostile, even if that isn’t the intent. This line alone comes across as very, “Sir, yes sir” as the only valid response, and it’s a line I couldn’t have said (something-something-about-gendered-allowances-etc.)
It is not hostile in the least, if anything it is actually an anxiety driven move to prevent conflict on the other thread as there has been a flurry of 'technobabble' recently and I intend to be more active again in a short time and do not want a backlash of complaints directed at myself or anyone else. I respect all viewpoints shared here and on that thread but some are mutually-exclusive and thus if the community wants a separate thread then we will have a separate thread, then everyone can be happy. It's really that simple.
I also find it curious this is coming up right now and not, say, quite some time ago, back when I was still heavily involved with getting Snow Leopard running smoothly on PowerPC Macs. And although I’m not going to take this personally, I do gather the tenor of your comments here — including the lol emoji — feel awfully personal by nature. (Or maybe that’s a total misread, idk.) If you have had a grievance with me, there’s been nothing here which couldn’t have been brought up with direct, person-to-person communiction (i.e., pm).
It is a total misread. I have nothing but respect for you @B S Magnet and have enjoyed our interactions over the last 4 years. It 'tickled me' because I feel like I knew what your vote would be and was correct that's all.
Anyhow, I’m not actively involved in the main project and I haven’t been for a while. It’s never meant I lost interest, but I did grow tired for the aforementioned reasons of project drift/creep. I would like to return to it again (because I like using Snow Leopard as a “regular driver” on my fastest available PPC Mac). And when I do so, my focus will resume on the basic remit laid out in the original post by Lars and early replies by vddrnnr.
I do not and it certainly is not. If I had a problem with you as a person you would know it as i can be very blunt and forward when the situation calls for it, and you would be greeted with a pm. Please don't read that as threatening at all, or hostile because it isn't intended to be. I hope that clears up any misunderstanding.
This is true. Current link for the 10.6.8 dmg also included in the wikipost.
A problem that arose with the other thread was the word count limit for posts. @B S Magnet managed to convince the mods to increase it for that thread, a number of times, and also finely tuned the formatting of that wiki. There is a limit however and so this thread will have information spread across posts 1-3.
I’m still figuring out which content will be best suited for posts #2 and #3 - will most likely end up being static information that will not need to be changed i.e instructions and useful references perhaps. All WIP.
