10.6 Snow Leopard PowerPC Development

ChrisCharman · Oct 10, 2024

Mac OS X 10.6.8

Snow Leopard PowerPC Development thread

‘The home of the community effort to develop, test and reconstruct Apple’s Mac OS X 10.6.8 Snow Leopard, for PowerPC G4 and G5 vintage Macs’

Post #1 — Current Project & Testing Hub (Wikipost)
Post #2 — Project History & Engineering Lineage

Post #3 — Xcode & Developer Tools

INTRODUCTION

This thread serves as 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.
[Alternative Mirror]

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:

Mac OS X 10.6.8 system components;
PowerPC-compatible components retained from earlier Snow Leopard Developer Previews, particularly 10A190;
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, it is 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 Developer Preview work and the mature 10A096 compatibility branch, see:

Snow Leopard on Unsupported PowerPC Macs

THREAD MAP

Post	Purpose
Post #1	Current project state, A5 downloads, installation, compatibility status, testing and contribution guidance.
Post #2	Project history and engineering lineage from the early Developer Previews through 10A190, 10A222, 10A432 and the later 10.6.8 (A5) build.
Post #3	Xcode, native PowerPC developer tools, SDKs, DarwinBuild, Mach-O inspection and reproducible source-build methodology.

PROJECT BRANCHES

The principal Snow Leopard builds used by the project are related, but not interchangeable.

Build / branch	Role	Current value
10A096 Client .iso Apple_Mac_OS_X_10.6_10A96_Client.cdr (7.11 GB) MD5: bedfab4a6bad12651e084fef496db0b9 10A096 Server .iso 10.6_snowleopard_DP_10A96_serverdvd.dmg (7.11 GB) MD5: 85bcc81ca4f1faca36750e20cb9a853f Restore image: 10A096_Clean.dmg (6.00 GB) @ChrisCharman MD5: db3ca38ab6c11f07c96f41689e136c6e	Early Developer Preview / mature compatibility branch	Comparatively Leopard-proximate and extensively tested. The original thread contains a detailed component-by-component compatibility record.
Restore Image: 10A190 .dmg @Larsvonhier PPC_SL_10A190.dmg (3.18 GB) MD5: d951ddc7e07abab23e460fcb7d5dc0fa 10A190 Client .iso 10.6_snowleopard_10a190_clientdvd.iso (7.36 GB) MD5: dae12c2f7b87b545cede6f517a66c10e	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 Client .iso 10.6_snowleopard_10a222_clientdvd.iso (6.98 GB) MD5: b3cbedebf921de1f4e9bfea7d3fb8953 10A222 Server .iso 10.6_snow_leopard_10a222_server_dvd.iso (7.06 GB) MD5: 0929662caf447e3ee34b505aa01caf84 *Other intermediate builds; 10A261 Client / Server .iso 10A286 Client .iso 10A314 Client .iso 10A354 Client .iso 10A380 Client .iso 10A380 Server .iso,	Comparative / experimental bridge	Useful for identifying approximately when APIs, binaries and PowerPC implementation paths changed during Apple’s Snow Leopard development.
Golden Master 10A432 Client .iso Mac_OS_X_10.6_Internal_Edition.zip (6.11 GB) MD5: 66dd247e771e1ecfc1310159fa217e05 Internal Edition Software Internal_Use_Software.iso (4.38 GB) MD5: 3fea4c5c93f988f8d4e1aaa648b925ab	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_PPC Alpha Base image @educovas Replaced Files: SL_PPC_replacedFiles.tar_.gz 10.6.8_PPC (A2) 10.6.8_PPC (A3) 10.6.8_PPC (A4) 10.6.8_PPC_ALPHA4_Jan21.dmg (3.52 GB) MD5: fab398758526aa48ac179286556b695b 10.6.8 (A5)Mirror #2 (3610.37 MiB / 3785.75 MB) Md5:131ee805d0a9fae7d9707335235d52f5e7bc39f8 10.6.8 (A5) Mirror #2 10.6.8_PPC_A5.dmg (3.53 GB) MD5: 271e7ce657b741b7f9130e7a4d2fefce	Current later-Snow-Leopard development branch	Primary public testing and reconstruction environment.

Macintosh Repository archive
Macintosh Garden archive

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.

DOWNLOADS

Download	Purpose	Notes
Mac OS X 10.6.8 PowerPC — Alpha 5	Current public testing image	10.6.8-derived SLPPC development environment. Preserve the exact image/source used when reporting results.
Earlier A-series images	Historical / regression testing	Useful when determining when a behaviour changed. Always identify the exact revision.
Xcode & PowerPC Developer Tools	Native development environment	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.

Useful source references:

For development purposes, however:

Code:

PPC source exists
→ PPC object builds
→ final binary links
→ correct PPC Mach-O is produced
→ correct artefact is installed
→ intended consumer actually loads it
→ required functionality works

Each step represents a different level of evidence.

A PowerPC implementation existing in the source is important, but does not by itself prove that the complete runtime path works.

Detailed developer/source-build methodology is maintained in Post #3.

NATIVE POWERPC DEVELOPMENT

A usable native development environment is now available on Snow Leopard PowerPC.

A historically demonstrated configuration based upon Xcode 3.2.6 plus targeted PowerPC developer-tool replacements made the fundamental:

Code:

gcc
as
ld
make

tool path usable for real software builds.

This should not be interpreted as proof that every executable installed by Xcode 3.2.6 is PowerPC-native.

The complete maintained developer-tool documentation, historical package state, DarwinBuild guidance and reproducible build workflow now live in:

Post #3 — Xcode & Developer Tools for Snow Leopard PowerPC

Related external projects:

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.

HIGHEST-VALUE REFERENCE REQUEST — UNTOUCHED 10A432

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:

Post #3 — Xcode & Developer Tools

For system-level development, please distinguish:

Code:

source support
→ compilation
→ linking
→ PPC artefact verification
→ installation
→ runtime loading
→ semantic/function validation

A successful compilation is useful evidence. It is not, by itself, proof that an operating-system component has been successfully ported or that a subsystem is fixed.

SOURCE CODE & TECHNICAL REFERENCES

Resource	Use
Apple OSS Distributions	Preserved Apple open-source repositories and release tags.
XNU 1504.15.3	Final Snow Leopard 10.6.8 XNU source generation.
Apple Developer Documentation Archive	Historical Mac OS X developer and system documentation.
Snow Leopard on Unsupported PowerPC Macs	Original Developer Preview project, historical testing and mature 10A096 compatibility Wiki.
Post #2 — Project History	Development chronology and engineering lineage.
Post #3 — Xcode & Developer Tools	Native PPC toolchain, SDKs, DarwinBuild and source-build methodology.
PowerPC Ports	Separate maintained software-porting ecosystem providing extensive real-world Snow Leopard PPC build evidence.
macos-powerpc.org	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;
Xcode/CLI/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:

Post #2 — Project History & Engineering Lineage

For Xcode, native PowerPC development tools, SDKs, DarwinBuild and source-build methodology:

Post #3 — Xcode & Developer Tools for Snow Leopard PowerPC

The most useful contribution is a reproducible result—working or broken—with enough information for somebody else to test it again.

⚠ WARNING ⚠️

This software is experimental and it 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.

…

ChrisCharman · Oct 11, 2024

Project History & Engineering Lineage

ABOUT THE PROJECT

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:

Snow Leopard on Unsupported PowerPC Macs

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.

On 21 April 2020, the original:

Snow Leopard on Unsupported PowerPC Macs thread was created.

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:

The core question became:

Code:

[/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

but increasingly became:

Code:

identify producer
→ identify correct source generation
→ reconstruct build
→ verify PPC artefact
→ integrate
→ validate at runtime

TWO COMPLEMENTARY DEVELOPMENT PATHS

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:

xnu-1504.15.3

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:

Code:

source
→ object
→ linked artefact
→ installed artefact
→ loader/runtime visibility
→ functional validation

2024 — LARGE-SCALE OPEN SOURCE RECONSTRUCTION

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.

On 10 October 2024, this dedicated:

10.6 Snow Leopard PowerPC Development

thread was therefore opened.

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.

For current operating-system status and testing:

Post #1 — Current Project & Testing Hub

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 resulting environment demonstrated working:

Code:

gcc
as
ld
make

and was used to build real software.

The original report can be found in:

this thread — page 10, post #244

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:

Post #3 — Xcode & Developer Tools

2026 — EVIDENCE-DRIVEN RECONSTRUCTION

As the project accumulated more reconstructed components, another limitation became increasingly obvious:

Knowing that a particular file or workaround once appeared to work is no longer sufficient.

For later Snow Leopard reconstruction we increasingly need to establish:

[]the exact target OS build/image;
[]the actual binary installed;
[]its architecture slices;
[]its producer/source generation;
[]its imported and exported interfaces;
[]which consumer requires it;
[]whether it is actually loaded;
[]whether the intended functionality works.

This has led to a more explicit engineering sequence:

Code:

PROVENANCE
→ TARGET / FREEZE
→ DIFF
→ CLASSIFY
→ CONTRACT
→ IMPLEMENT
→ COMPILE
→ LINK / ARTEFACT VERIFY
→ BOOT
→ RUNTIME / SEMANTIC VALIDATE

This does not replace experimentation.

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:

Post #1 — Current Project & Testing Hub

For Xcode, native PowerPC developer tools, SDKs and toolchain reconstruction:

Post #3 — Xcode & Developer Tools

For the original Developer Preview investigation and mature 10A096 compatibility work:

Snow Leopard on Unsupported PowerPC Macs

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.

ChrisCharman · Oct 11, 2024

View attachment 2479890

XCODE & DEVELOPER TOOLS FOR SNOW LEOPARD POWERPC

Native development, Apple toolchains, SDKs and source-build reconstruction

Post #1 — Current Project & Testing Hub • Post #2 — Project History & Engineering Lineage • Post #3 — Xcode & Developer Tools

Last major technical review: 1 September 2026

PURPOSE OF THIS POST

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.

A useful rule is:

Code:

Leopard 10.5.8        → Xcode 3.1.4
Snow Leopard 10A190  → Xcode 3.2 from 10A190
Snow Leopard 10.6.8  → Xcode 3.2.6 + PPC tool replacements

The compiler and developer environment should normally correspond to the OS generation being targeted.

XCODE 3.2.6 DOWNLOAD

The current PowerPC Ports installation guide uses the standard Apple Xcode 3.2.6 release as the 10.6 development foundation.

Current maintained instructions:

PowerPC Ports — Installation Guide

Preserved installer:

Xcode 3.2.6 and iOS SDK 4.3 — Archive.org

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?

HISTORICALLY VALIDATED MINIMUM 10.6.8 PPC TOOLCHAIN

On 20 January 2025, @barracuda156 documented a controlled native setup starting from a clean Snow Leopard 10.6.8 installation.

The sequence was:

Code:

Mac OS X 10.6.8 PowerPC
+
standard Xcode 3.2.6
+
darwin-developer-tools 1.1.0
+
PPC-compatible ld64 97.17
+
PowerPC GNU/Apple make 3.81

The resulting environment successfully provided:

Code:

gcc
as
ld
make

and was used to build real software.

Historical discussion:

10.6 Snow Leopard PowerPC Development — page 10, post #244

The importance of this result is that it established a demonstrated minimum native command-line environment.

It explicitly did not establish that every Intel-only executable installed by Xcode 3.2.6 had been replaced.

THE HISTORICAL JANUARY 2025 INSTALLER SET

Three packages were published for that configuration:

Package	Purpose	Current evidence state
sl-ld64-97.17.zip	PPC-compatible Apple ld64 97.17 and associated linker tools. LTO disabled for this compatibility build.	Historical endpoint remained available when last checked on 29 August 2026.
sl-make-3.81.zip	PowerPC build of GNU/Apple make 3.81 for the Snow Leopard system environment.	Historical URL currently missing / 404 when last checked. Source recipe remains recoverable.
darwin-developer-tools-1.1.0.zip	cctools-focused PPC developer-tool replacement derived from Iain Sandoe’s Darwin tooling work.	Historical URL currently missing / 404 when last checked. Source provenance remains recoverable.

The original URLs and context remain preserved in post #244.

Historical source recipe snapshot:

PowerPC Ports source tree — January 2025 snapshot

Specific recipes:

[]sl-ld64
[]sl-make

Archive provenance matters.

A package rebuilt today from the historical source recipe should be described as:

Code:

RECONSTRUCTED FROM SOURCE

unless it has been demonstrated byte-for-byte identical to the original historical package.

CURRENT MAINTAINED POWERPC PORTS TOOLCHAIN PATH

The January 2025 package set is a valuable historical known-good configuration.

It should not be confused with the permanently current installation procedure.

PowerPC Ports has continued to evolve and maintains current Snow Leopard installation instructions here:

PowerPC Ports — Snow Leopard Installation Guide

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.

Repository:

macos-powerpc/powerpc-ports — GitHub

Related project site:

macos-powerpc.org

PowerPC Ports is not part of the SLPPC operating-system project.

However, it is extremely valuable to SLPPC because it provides sustained real-world native compilation workloads.

A system which can build:

[]GCC;
[]Qt;
[]multimedia software;
[]networking software;
[]large dependency graphs;
[]modern command-line packages;

is exercising far more of the compiler, linker, libc, framework and filesystem environment than a trivial “Hello World” build.

PowerPC Ports therefore acts as an important practical validation workload for Snow Leopard PowerPC.

CCTOOLS

Apple’s cctools family provides the traditional Darwin/Mach-O compiler tools.

Important members include:

Tool	Purpose
`as`	Assembler
`ar`	Static archive creation/manipulation
`nm`	Symbol-table inspection
`ranlib`	Archive symbol index generation
`otool`	Mach-O headers, load commands, dependencies and disassembly
`lipo`	FAT/Universal architecture inspection and manipulation
`libtool`	Darwin archive/library construction
`strip`	Symbol/debug-information removal
`size`	Mach-O size/section reporting
`strings`	Printable-string inspection

Useful Apple source:

A particularly important trap is that the operating system and Xcode developer tree can contain different generations of nominally the same tool.

For example:

Code:

/usr/bin/


/Developer/usr/bin/

may not have the same:

[]version;
[]architecture slices;
[]build provenance;
[]behaviour.

Never report simply:

“cctools works”

without establishing which cctools binary actually executed.

DARWIN-XTOOLS

A major modern resource is Iain Sandoe’s:

darwin-xtools

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.

Apple source:

Apple OSS — ld64

Snow Leopard-era source used by the historical SLPPC setup:

ld64-97.17

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.

Apple source:

Apple OSS — gnumake

The historical January 2025 toolchain used a PowerPC build of make 3.81.

Verify the actual executable being invoked:

Code:

which make
type -a make
make –version
file “$(which make)”

Do not assume PATH determines every build.

Some Apple projects and Xcode build systems invoke tools from fixed locations such as:

Code:

/usr/bin


/Developer/usr/bin

This is a recurring reason why one manually tested copy of a tool can appear to work while an automated build still fails with:

Code:

Bad CPU type in executable

M4, BISON AND OTHER DEVELOPER UTILITIES

Xcode installs many secondary build utilities.

Some later Snow Leopard copies are Intel-only or otherwise unsuitable for a native PPC environment.

Known examples requiring attention in fuller development configurations include:

[]m4 / gm4;
[]bison;
[]developer-tree copies under /Developer/usr/bin;
[]other auxiliary Xcode command-line tools.

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:

Code:

SDKROOT=/Developer/SDKs/MacOSX10.6.sdk
MACOSX_DEPLOYMENT_TARGET=10.6
ARCHS=ppc

Depending on the build system, equivalent compiler arguments may include:

Code:

-isysroot /Developer/SDKs/MacOSX10.6.sdk
-arch ppc
-mmacosx-version-min=10.6

Apple/Darwin makefiles may instead or additionally use variables such as:

Code:

RC_ARCHS
RC_NONARCH_CFLAGS
RC_ProjectName
DSTROOT
OBJROOT
SYMROOT
SDKROOT

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:

Code:

/usr/bin/
/Developer/usr/bin/
/opt/local/bin/
/usr/local/bin/

The shell may resolve one copy while an Apple makefile or Xcode project invokes another directly.

Therefore:

“The tool works when I run it in Terminal” does not prove the build system is running the same binary.

MACH-O ARCHITECTURE VERIFICATION

Before installing a rebuilt system binary, verify the artefact itself.

Useful commands:

Code:

file ./binary


lipo -info ./binary


otool -hv ./binary


otool -L ./binary


nm ./binary

For Universal binaries:

Code:

lipo -archs ./binary

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:

Code:

PPC slice exists
≠
correct PPC binary
≠
correct dependencies
≠
runtime compatibility

SYMBOLS: SOURCE → BINARY → CONSUMER

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:

cctools-750

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.

Useful entry points:

The Developer Tools distribution also links source projects such as:

[]bison;
[]bootstrap_cmds;
[]developer_cmds;
[]flex;
[]gm4;
[]gperf;
[]CoreOSMakefiles;
[]other development infrastructure.

This provides many of the source producers needed when an installed developer binary lacks PPC support.

However:

Apple releasing source does not prove that the release corresponds exactly to a particular installed Xcode binary.

Source version, installed binary version and release/build provenance must still be reconciled.

DARWINBUILD

DarwinBuild is Apple’s/Mac OS Forge’s historical build-reconstruction framework for Darwin projects.

It provides tools including:

[]darwinbuild;
[]darwinxref;
[]darwintrace;
[]darwinup.

Its original design can:

[]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.

SLPPC therefore uses DarwinBuild primarily as:

[]historical build metadata;
[]dependency evidence;
[]a reconstruction aid;
[]a source of build methodology;

with project-specific adaptation where required.

APPLE SOURCE BUILD RECONSTRUCTION

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.

[/LIST]

For SLPPC this is represented more generally as:

Code:

PROVENANCE
→ TARGET / FREEZE
→ DIFF
→ CLASSIFY
→ CONTRACT
→ IMPLEMENT
→ COMPILE
→ LINK / ARTEFACT VERIFY
→ BOOT
→ RUNTIME / SEMANTIC VALIDATE

SOURCE VERSION IS NOT SHIPPING VERSION

An important project rule is:

Code:

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

Then inspect the actual binaries:

Code:

file “$(which gcc)”
file “$(which as)”
file “$(which ld)”
file “$(which make)”


lipo -info “$(which as)”
lipo -info “$(which ld)”

Record this information with the build.

DO NOT REPLACE TOOLS BLINDLY

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.
T2	Capture stock Xcode 3.2.6 / 10.6.8 counterpart binaries and architecture slices.	Establishes exactly what each replacement is replacing.
T3	Construct an exact replacement map and producer/consumer dependency graph.	Separates system tools from Xcode tools and avoids unnecessary replacement.
T4	Reproduce a controlled native PPC build using the minimum reconstructed tool set.	Turns historical reports into a fully reproducible modern baseline.
T5	Add m4, bison and other tools only when a real build demonstrates the requirement.	Keeps toolchain reconstruction evidence-driven rather than speculative.

Archive recovery requested

If anyone has original copies of:

Code:

sl-make-3.81.zip


darwin-developer-tools-1.1.0.zip


sl-ld64-97.17.zip

please preserve the original unmodified archives.

Useful accompanying information includes:

Code:

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.

For example:

Code:

mkdir -p build/obj
mkdir -p build/sym
mkdir -p build/dst

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.

Preserved documentation:

macOS Forge — DarwinBuild Documentation

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.

Its greatest value to SLPPC is as a:

provenance + dependency + controlled-build framework.

DARWINBUILD ROOTS ARE IMPORTANT EVIDENCE

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

Sources:

[]Apple OSS Distributions
[]DarwinBuild build plists;
[]Apple release/source metadata;
[]untouched installation media;
[]package receipts/BOMs;
[]known-good binary version strings;
historical DarwinBuild Roots.

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?

Then identify the contract connecting them.

Examples include:

[]Mach-O imported/exported symbols;
[]framework APIs;
[]static-library membership;
[]KPI/KEXT exports;
[]launchd/Mach service names;
[]MIG interfaces;
[]configuration/plist contracts;
[]filesystem paths.

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.

This distinction is particularly important for:

[]XNU;
[]KEXTs;
[]libSystem constituents;
[]private frameworks;
graphics compatibility wrappers.

STATIC LIBRARIES AND LIBSYSTEM

Some Darwin projects produce static libraries specifically to be consumed while building another system component.

These must not automatically be treated as standalone shipping libraries.

For example, current SLPPC source-producer work has established the build relationship:

Code:

cctools-750/libmacho
→ libmacho.a
→ /usr/local/lib/system/libmacho.a
→ consumed during Libsystem construction

This identifies a build-time producer relationship.

It is not, by itself, evidence for a separately shipping:

Code:

/usr/lib/libmacho.dylib

on retail Snow Leopard.

This producer/consumer distinction should be preserved for every reconstructed static constituent.

POWERPC ENDIANNESS

PowerPC Macs are big-endian in the ordinary SLPPC environment.

Later source written primarily for Intel may contain assumptions which compile successfully but behave incorrectly on PPC.

When reconstructing later code, audit for:

[]byte-order assumptions;
[]packed structures;
[]bitfields;
[]network-order conversion;
[]unaligned access;
[]serialization/deserialization;
[]binary file formats;
[]atomic operations;
[]assembly implementations;
[]conditional compilation using endian macros.

Do not add endian patches merely because the target is PPC.

First determine whether the relevant code path is actually endian-sensitive and whether an existing Apple PPC implementation already handles it.

PPC AND PPC64 ARE SEPARATE TARGETS

PowerPC support should not automatically be represented as one binary state.

Architecture	Scope
ppc	32-bit PowerPC and the primary compatibility target across G4 and G5 hardware.
ppc64	64-bit PowerPC, applicable only to G5-class hardware and projects which genuinely implement/support the architecture.

A project which compiles for:

Code:

ppc

has not thereby been validated for:

Code:

ppc64

and vice versa.

Where both are relevant, verify each slice independently.

CURRENT POWERPC PORTS ENVIRONMENT

PowerPC Ports is a separate project maintained for modern software on PowerPC macOS.

Its Snow Leopard work is highly relevant because it provides a continuously exercised real-world development environment on 10.6.8 PowerPC.

Current installation instructions:

PowerPC Ports — Installation Guide

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.

HISTORICAL TOOLCHAIN ARCHIVES — EVIDENCE BOUNDARY

The January 2025 toolchain was distributed as:

Code:

sl-ld64-97.17.zip
sl-make-3.81.zip
darwin-developer-tools-1.1.0.zip

At the latest project verification:

Archive	Verified endpoint state
sl-ld64-97.17.zip	Historical endpoint remains reachable as a ZIP.
sl-make-3.81.zip	Historical URL currently unavailable / 404.
darwin-developer-tools-1.1.0.zip	Historical URL currently unavailable / 404.

The original forum publication establishes historical provenance.

However, until original archive bytes are recovered and inspected, do not invent or assume:

[]SHA-256 hashes;
[]exact installer package names;
[]complete payload lists;
[]Mach-O slices;
[]binary build strings;
[]byte-for-byte equivalence with a later source reconstruction.

Where an original archive can no longer be recovered, a package rebuilt from the corresponding source recipe should be described explicitly as:

RECONSTRUCTED FROM SOURCE

rather than as the original historical installer.

REPRODUCIBLE DEVELOPMENT REPORT

When posting a system-component or developer-tool build, the following template is recommended.

Code:

SLPPC DEVELOPMENT BUILD REPORT


TARGET
OS build:
Component:
Expected install path:
Architecture:
ppc / ppc64 / universal:


SOURCE
Project:
Exact source version/tag:
Source URL/archive:
Source hash if available:
Patches/diff:


BUILD HOST
Machine:
Host OS:
Xcode:
SDK:


TOOLCHAIN
CC:
CXX:
AS:
LD:
MAKE:
Other required build tools:


PATH:
SDKROOT:
MACOSX_DEPLOYMENT_TARGET:
ARCHS:
RC_ARCHS:


DEPENDENCIES
Header Roots:
Library Roots:
Static libraries:
Generated files:
Build-only tools:


BUILD
Exact command:
SRCROOT:
OBJROOT:
SYMROOT:
DSTROOT:


RESULT
Build successful:
Produced artefact(s):


VERIFICATION
file:
lipo -info:
otool -L:
relevant nm output:
version/build string:


INSTALLATION
Original file preserved:
Install path:
Owner/group:
Permissions:
Extended attributes:
Cache/rebuild actions:


RUNTIME TEST
Consumer/subsystem:
Expected:
Actual:
Relevant logs:


VALIDATION LEVEL
Source identified /
Compiles /
Links /
PPC artefact verified /
Installed /
Loaded /
Runtime function validated


KNOWN LIMITATIONS:

Not every forum report needs every field.

The important requirement is that a claim can be traced back to enough information for another developer to reproduce or falsify it.

WHEN REPORTING A SUCCESSFUL BUILD

Please avoid reporting only:

Code:

Built successfully for PPC.

A substantially more useful report is:

Code:

Project/version:
Target build:
Compiler:
Assembler:
Linker:
SDK:
Architecture:
Build command:
Produced binary:
file/lipo result:
otool result:
Installed:
Runtime-tested:

This distinguishes:

BUILD SUCCESS

from:

PORT SUCCESS

and both from:

SUBSYSTEM FIX VALIDATED.

WHEN REPORTING A FAILURE

Failed builds are also useful evidence.

Include:

[]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.

DEVELOPMENT RESOURCES

Resource	Purpose
Apple OSS Distributions	Preserved Apple open-source project repositories and release tags.
XNU 1504.15.3	Final Snow Leopard 10.6.8 XNU source generation.
darwin-xtools	Modernised Darwin cctools/ld64 work with restored PPC/PPC64 support.
DarwinBuild source	Historical Darwin source-build and dependency framework.
DarwinBuild documentation	Preserved instructions, build model and HOWTO material.
PowerPC Ports	Current PowerPC macOS software-porting project and native Snow Leopard validation environment.
PowerPC Ports installation guide	Current maintained Snow Leopard developer-tool/bootstrap procedure.
macos-powerpc.org	PowerPC macOS development resources and historical SLPPC/PPCPorts material.
Apple Developer Documentation Archive	Archived Apple technical documentation.

SCOPE OF THIS POST

This post is the development-tool authority for the SLPPC thread.

It should contain:

[]Xcode;
[]compiler/toolchain state;
[]developer utilities;
[]SDKs and headers;
[]DarwinBuild;
[]Apple source-build methodology;
[]Mach-O inspection;
[]reproducible build instructions;
toolchain recovery/testing.

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.

Historical project narrative belongs in Post #2.

THREAD NAVIGATION

Post	Purpose
Post #1	Current Snow Leopard PowerPC project state, A5, installation, subsystem testing and contribution guidance.
Post #2	Project history and engineering lineage.
Post #3	Xcode, developer tools, native PowerPC toolchain and source-build methodology.

Original Developer Preview project:

Snow Leopard on Unsupported PowerPC Macs

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.

View attachment 2479491

Doq · Oct 11, 2024

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.

educovas · Oct 11, 2024

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.

barracuda156 · Oct 11, 2024

educovas said:
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.

ChrisCharman · Oct 11, 2024

educovas said:
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’ve left the first two posts intentionally blank on this thread for that potential eventuality.

B S Magnet · Oct 13, 2024

ChrisCharman said:
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 welcome the feedback.

ChrisCharman · Oct 14, 2024

B S Magnet said:
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 welcome the feedback.

I already knew your vote before creating the poll @B S Magnet 😂

B S Magnet · Oct 14, 2024

ChrisCharman said:
I already knew your vote before creating the poll @B S Magnet 😂

My vote is beside the point, Chris.

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.

Thank you for doing this.

ChrisCharman · Oct 14, 2024

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.

B S Magnet · Oct 14, 2024

ChrisCharman said:
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.

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.

ChrisCharman said:
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.

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 4 was 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.

ChrisCharman said:
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. 🤷‍♀️

ChrisCharman said:
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.

ChrisCharman said:
@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’.

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.

ChrisCharman said:
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.

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.

ChrisCharman said:
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.

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.”

ChrisCharman said:
It is a community decision and the outcome will be respected.

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.

barracuda156 · Oct 14, 2024

B S Magnet said:
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 4 was 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.

ChrisCharman · Oct 15, 2024

barracuda156 said:
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.

In defence of @B S Magnet - they are simply responding honestly and fully to the points I’ve mentioned.

ChrisCharman · Oct 15, 2024

Larsvonhier said:
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?

Regarding the purpose of the thread and wiki including Xcode up to 3.2.6

Larsvonhier said:
Intel (apps) outside ;-)
(No they would not 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

Regarding the benefits of running Snow Leopard and Xcode on PowerPC

Larsvonhier said:
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!

Early attempts to get 10A222 functional on PowerPC

Larsvonhier said:
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.

Discussion regarding compiling from source and sourcing at least some components from later builds or from Leopard

ChrisCharman said:
@Larsvonhier

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

B S Magnet said:
Please do! Not sure how much of the OS build the open-source components for SL cover, but they could be helpful!

Welcoming open-source components

Larsvonhier said:
I would not call it that for 1.5 reasons ;-)

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.)

Regarding renaming the project

Larsvonhier said:
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..

Further discussion regarding getting the retail kernel working on PowerPC

Larsvonhier said:
…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.

Let´s see what we find out.

Predicting a fork in the road

ChrisCharman said:
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.

Me doing what I said i was going to do

ChrisCharman · Oct 15, 2024

B S Magnet said:
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.

B S Magnet said:
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.

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.

B S Magnet said:
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 4 was 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.

B S Magnet said:
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.

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.

B S Magnet said:
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.

B S Magnet said:
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.

B S Magnet said:

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.

Click to expand...

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'.

B S Magnet said:

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.

Click to expand...

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.

B S Magnet said:

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.”

Click to expand...

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?

B S Magnet said:
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.

B S Magnet said:
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.

B S Magnet said:
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.

Please do, i look forward to it.

B S Magnet said:
But if you take umbrage with me as a person, then this is not the place for it.

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.

B S Magnet said:
p.s., The poll’s data would be more effective with checkboxes, not radio buttons.

This is the first poll i've posted on MacRumors and i'm unfamiliar with the options.

Tankerthebuberz · Oct 16, 2024

anyone have an updated download link for the 10.6.8 image....it looks like it was removed from megaupload

Tankerthebuberz · Oct 16, 2024

great work by the devs btw!

ChrisCharman · Oct 16, 2024

Tankerthebuberz said:
great work by the devs btw!

Yes, here is the latest version uploaded by @educovas incorporating some new binary and framework fixes:

10.6.8 PowerPC (Test version 2)

The link in the wikipost has been updated to direct to the latest image.

Project Alice · Nov 4, 2024

How did I not see this thread until now. This'll give me something to do my next weekend

barracuda156 · Nov 5, 2024

ChrisCharman said:
Yes, here is the latest version uploaded by @educovas incorporating some new binary and framework fixes:

10.6.8 PowerPC (Test version 2)

The link in the wikipost has been updated to direct to the latest image.

> The file you are trying to download is no longer available

Doq · Nov 5, 2024

barracuda156 said:
> The file you are trying to download is no longer available

This post has a good link: 10.6.8_PPC.dmg (mega.nz)

Main post updated as well.

ChrisCharman · Nov 5, 2024

The WikiPost of this thread will always contain the most recent updates and download links

Doq · Nov 5, 2024

Post #2 is not widely editable as part of a WikiPost.

ChrisCharman · Nov 6, 2024

Doq said:
Post #2 is not widely editable as part of a WikiPost.

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.

10.6 Snow Leopard PowerPC Development

Should continued work on 10.6.8 PowerPC and Xcode 3.2.X have its own dedicated thread?

Yes - The original thread is for the developer previews and all this dev jargon is derailing it!

Yes - I would like to be able to follow and/or contribute to a 10.6.8/Xcode thread specifically

Yes - I would like to be able to follow and/or contribute to a Developer Preview thread specifically

Indifferent - I don't care either way i just appreciate the work that's being done

No - The thread is already for Snow Leopard on PowerPC and all discussion is welcome and relevant

macrumors 6502a

​

Mac OS X 10.6.8 ​

Snow Leopard PowerPC Development thread​

INTRODUCTION​

This is an experimental development project, it is not a finished operating system release.​

​

THREAD MAP​

PROJECT BRANCHES​

PROJECT HISTORY​

⚠ WARNING ⚠️ ​

macrumors 6502a

Attachments

macrumors 6502a

Attachments

macrumors 6502a

macrumors regular

macrumors 601

macrumors 6502a

macrumors 603

Should continued work on 10.6.8 PowerPC and Xcode 3.2.X have its own dedicated thread?​

macrumors 6502a

macrumors 603

macrumors 6502a

macrumors 603

macrumors 601

macrumors 6502a

macrumors 6502a

macrumors 6502a

Suspended

Suspended

macrumors 6502a

macrumors 68020

macrumors 601

macrumors 6502a

macrumors 6502a

macrumors 6502a

macrumors 6502a

Our Staff

Mac OS X 10.6.8

Snow Leopard PowerPC Development thread

INTRODUCTION

This is an experimental development project, it is not a finished operating system release.

THREAD MAP

PROJECT BRANCHES

PROJECT HISTORY

⚠ WARNING ⚠️

Should continued work on 10.6.8 PowerPC and Xcode 3.2.X have its own dedicated thread?