10.6 Snow Leopard PowerPC Development

[jktwice]

Well, has anyone managed to backport a newer version of WebKit (or compile it from source) to PPC Snow Leopard or is it more trouble than solution because the services / apps that use WebKit might not work properly? Well, we can't think the situation with the Leopard WebKit would get better other than much worse in the future. When even the Snow Leopard WebKit (barely) manages to load some simpler webpages (In native x86_64, NOT PPC), it's honestly questionable that porting even Snow Leopard WebKit (The final ones) to PPC would make sense. We'd need something later for an actually usable web browsing experience. But, if our target here is just get the web services running, I think porting Snow Leopard's WebKit would be much more preferable than the Leopard one. But even that would be a near-impossible situation because many parts of macOS depends on the WebKit, not just Safari. But one thing I know for sure, the WebKit framework stack of 10.6 (Native Intel x86_64) can still sync with Apple's Update Servers (at least as of May 2025) as in this photo of one of my fun-time experimentations:

I just don't see why we need newer WebKit on here. You're going to get maybe a slightly newer version than I think Safari 11? It's whatever High Sierra uses I believe. The deal though is that there's a current browser being developed called PowerFox and that has a lot of excitement around it. Would rather have developers spend the resources porting the TFF JIT over to PowerFox than try and update WebKit. There's really not a lot of manpower to go around. Gotta be smart with this.

 

[Dinul-SV]

I just don't see why we need newer WebKit on here. You're going to get maybe a slightly newer version than I think Safari 11? It's whatever High Sierra uses I believe. The deal though is that there's a current browser being developed called PowerFox and that has a lot of excitement around it. Would rather have developers spend the resources porting the TFF JIT over to PowerFox than try and update WebKit. There's really not a lot of manpower to go around. Gotta be smart with this.

Well, WebKit IS NOT just Safari, many parts of macOS depends on the WebKit. For example, Mail, App Store (no point in using it anyways, no PPC compatible apps) and Safari-based web apps are directly dependent on the WebKit framework, making it an important thing to consider if we want a truly "native" experience of 10.6 on G4s and G5s. It's not just drag and drop of some framework bundles, there's a lot of internals with the risk of breaking catastrophically if you are careless. That's why I believe a new version of WebKit should be ported with care, not just because of Safari, but to keep many other parts of macOS running. Even Safari 11 would be better than whatever 10.5 or 10.6 would ever have (unless it's a modern community effort). At least it can still be reasonably performant in daily web browsing.

Also, has anyone compiled 10.6.8 Server kernel for PPC or is it just the consumer version 10.6.8 you've compiled here?

 

[barracuda156]

Also, has anyone compiled 10.6.8 Server kernel for PPC or is it just the consumer version 10.6.8 you've compiled here?

Do kernels differ?

 

[barracuda156]

It is preferable to have all third-party software discussions not relevant to the OS itself somewhere outside of this thread. While my primary work is on PPCPorts, it may not be the case for others, and it makes the thread overloaded with unrelated info. Likewise, I would appreciate getting PPCPorts-specific feedback in a dedicated thread, so that I do not miss it: https://forums.macrumors.com/threads/ppcports-the-only-ports-you-ever-need-on-a-powerpc.2462897/
Yet better, open an issue or discussion on GitHub or Codeberg in my repo.



I do not agree with the premise here, but a) you are welcome to test ports on 10.5 and submit fixes (unlike 10.4, I intend to support 10.5); b) if going via PRs is bothersome, you may fork either MacPorts directly or PPCPorts and commit whatever you prefer. In the latter case please make me aware of it, I am interested to pick suitable fixes.



Well, since nobody has or ever will ask for corporate support of ports on powerpc macOS, LOL, there is no strict requirement to prioritize stability over performance. There is a trade-off here. I like features that 10.6 provide, even in its current state. There are ports which I personally use that are broken on 10.5 but work on 10.6. So while I agree that 10.6 as we have it got issues, in my projects it will remain the system of reference. At least until someone backports features of 10.6 into 10.5.



Yes, but the aim of ports is to build software natively. It is indeed not meant to build for some alien SDK. AFAIK, MacPorts does not do that either, with very few select exceptions (which I also have some doubts about).
To build for 10.5, use 10.5. To build for 10.6, use 10.6. If this is unacceptable, please implement a functionality to support such builds, PRs are welcome (maybe even in upstream MacPorts).



1. This is always the case, in upstream MacPorts too. The solution is to test every port on every existing macOS (and at least some Linux) and to set supported_platforms value. Nobody does that, I guess nobody every will do that. While I agree it is desirable, it is just not feasible. So yes, it relies on contributions, by design.
2. I do not see why porting efforts is duplicated. Normally supporting an extra macOS version simply means a few additional fixes on top. If not, that means that earlier OS cannot support a newer version of a given port; here I rather have a newer version on 10.6 than being constrained by deficiencies of 10.5.



I have a broken sleep in Catalina now (dunno why, no one responded on the topic). Turning off instead of sleeping is annoying, but costs of it are usually negligible.



Why this is even brought up here LOL
Iain does not test on 10.5 now, AFAIK, since his Quad is dead. (Anyone in UK to help?)
I am in touch with him, so if something goes badly wrong on 10.6, I will request for help. However, 10.6.8 SDK is nearly standard, and differences are totally inconsequential for gcc (OpenGL or CoreGraphics are not used by it). So the problem is mute, since we moved from 10a190 to 10.6.8.



Ok, I will make it more explicit that 10.5 is rarely tested. (It has been mentioned, but perhaps I indeed should emphasize it more.)



Please consider fixing mentioned issues in 10.6.8. That could be a better solution than being stuck on 10.5 just because sleep and old samba are broken.

Just to update on this: clean builds on 10.5 work just fine, IMO. It won’t be on par with 10.6.8, but no major issues.

 

[Dinul-SV]

Do kernels differ?

I think so, but I can't find much information in the internet though. The kernel was always different between client and server, even in 10.4 and older.

 

[barracuda156]

I think so, but I can't find much information in the internet though. The kernel was always different between client and server, even in 10.4 and older.

Surprising, I was sure it was a userland bells&whistles on top. But no idea really.

 

[Dinul-SV]

Server versions of macOS actually use different kernel versions than the client ones. For example, in beta versions of 10.6, there was a separate beta release for 10.6 Server (10A403) alongside the currently unreleased 10A402 or beta 9 of client/desktop 10.6. Another example is 10.6.5 having 2 release kernels as 10H574 for desktop and 10H575 for server. Even in 10.5 it was the same, beta versions had a separate server version as 9A528a and its desktop counterpart, 9A527 are the best example for it.

Surprising, I was sure it was a userland bells&whistles on top. But no idea really.

 

[b251]

Some icons are missing in the dock, like the one for Terminal:

 

[barracuda156]

Some icons are missing in the dock, like the one for Terminal:

View attachment 2609652

Which image is this? I encountered this issue once in a while, but never with Apple pre-installed apps. What I assumed was that icons are in wrong format/resolution, and the OS does not find a suitable icon to display. But that should not be the case with Apple Terminal, obviously.

 

[b251]

It’s the A5.

 

[Dinul-SV]

By the way, is it possible to backport GPU drivers (kexts) for GeForce 8/9/200-series (Tesla) to PPC, because if it's possible, it might be a dream come true, much faster GPUs in Power Macs.

 

[Smithwick’s]

By the way, is it possible to backport GPU drivers (kexts) for GeForce 8/9/200-series (Tesla) to PPC, because if it's possible, it might be a dream come true, much faster GPUs in Power Macs.

This actually occurred to me after I watched Action Retro's video putting an RTX (and other cards which have no business running on such hardware) in a PMG5 running PPC64 Linux. He had a few successes but I don't believe there are up-to-date Linux drivers for newer cards on PPC64 so you're still stuck with nouveau (boo) or radeon (ok). Finding a way to backport something to Snow Leopard could possibly unlock some wild upgrade potential. That being said, the real kicker will probably be the fact that much better cards released for OSX (but on the Mac Pro) are based on x86/64 compatibility. Both the drivers and the firmware would need to be successfully worked out or it's a no-go.
EDIT: ATI/AMD would almost certainly be the easier route FWIW (summoning the spirit of Linus T. famously telling off NVIDIA).

 

[Dinul-SV]

This actually occurred to me after I watched Action Retro's video putting an RTX (and other cards which have no business running on such hardware) in a PMG5 running PPC64 Linux. He had a few successes but I don't believe there are up-to-date Linux drivers for newer cards on PPC64 so you're still stuck with nouveau (boo) or radeon (ok). Finding a way to backport something to Snow Leopard could possibly unlock some wild upgrade potential. That being said, the real kicker will probably be the fact that much better cards released for OSX (but on the Mac Pro) are based on x86/64 compatibility. Both the drivers and the firmware would need to be successfully worked out or it's a no-go.
EDIT: ATI/AMD would almost certainly be the easier route FWIW (summoning the spirit of Linus T. famously telling off NVIDIA).

Of course, that would be the case, and AMD HD 2000/3000 would be a better bet than NVIDIA Tesla in any day, and I know the Radeon X1950 XTX works on PPC flawlessly (I've tried it), and it's currently the fastest GPU (or the nuclear reactor I should say) supported by PPC macOS, but 2000 series and beyond (as well as Tesla and beyond) would an absolute nightmare, because they use unified shaders and not fixed-function pipeline cores, and if you try to port the macOS kext itself, endianness would flip the bird on you as well, I think a better idea would be to use the Linux's GPU DRM (Direct Rendering Manager) code and make an IOKit wrapper for XNU (macOS), at least you know the core works in such a case.

 

[ChrisCharman]

Hi everyone,

For users testing image A5 and experiencing issues, i have provided a script that should fix any problems that are directly related to remnants of my user account remaining on the image. Please treat this script as untested.

Snow Leopard PPC A5 Post-Release Repair Utility


Version: 1.2

OVERVIEW

This utility repairs leftover developer-account artifacts from the released A5 image.

Specifically, it removes residual ownership and system state associated with:


powerpcdeveloper (UID/GID 501)

These remnants can cause:


- Incorrect file ownership
- Permission issues
- Network problems (self-assigned IP, DHCP failures)
- General system instability

WHAT THIS TOOL DOES

- Repairs system file ownership residue tied to UID/GID 501
- Restores critical permissions on key binaries
- Resets stale network configuration
- Rebuilds dyld and kext caches
- Preserves user home folders and personal data
- Offers optional performance tuning after the repair phase

WHAT THIS TOOL DOES NOT DO

- Does not wipe /Users
- Does not delete personal files
- Does not require reinstall

FILES INCLUDED


- slppc-a5-repair.sh Main repair script


- README.txt This document


- CHANGELOG.txt Version history

USAGE

Terminal method:


chmod +x slppc-a5-repair.sh


sudo ./slppc-a5-repair.sh


IMPORTANT NOTES


- You may need to reconfigure networking after reboot.


- A backup of network configuration is created automatically.


- The repair log is written to:


/var/log/slppc-a5-repair.log


or, if unavailable:


/tmp/slppc-a5-repair.log





- Backups are stored in:


/var/backups/slppc-a5-repair-*


RECOMMENDED WHEN


Run this utility if you experience:


- Broken networking


- Permission issues


- Strange ownership behavior


- A5 image contamination from the original build account


CREDITS

Snow Leopard PPC Project

ChrisCharman / ChatGPT

 

[FBSD_Mac]

Hi everyone,

For users testing image A5 and experiencing issues, i have provided a script that should fix any problems that are directly related to remnants of my user account remaining on the image. Please treat this script as untested.

Snow Leopard PPC A5 Post-Release Repair Utility


Version: 1.2

OVERVIEW

This utility repairs leftover developer-account artifacts from the released A5 image.

Specifically, it removes residual ownership and system state associated with:


powerpcdeveloper (UID/GID 501)

These remnants can cause:


- Incorrect file ownership
- Permission issues
- Network problems (self-assigned IP, DHCP failures)
- General system instability

Chris, are you saying this fixes DHCP so that an assigned IP address is no longer necessary?

 

[ChrisCharman]

DHCP was working for me when i created that image, however as i failed to fully remove my user account i believe this may be causing some of the issues for other users. It’s also possible that different hardware configurations are the route cause but i need people to test post script to find out more information.

 

[barracuda156]

DHCP was working for me when i created that image, however as i failed to fully remove my user account i believe this may be causing some of the issues for other users. It’s also possible that different hardware configurations are the route cause but i need people to test post script to find out more information.

Could you remind, did local AFP/SMB access worked without specific manual setup? I was able to get volumes from Catalina mounted in SL, but in involved some hacking. In 10.5 that works out-of-the-box.
P. S. Not ssh, ssh is fine everywhere.

 

[ChrisCharman]

As far as i recall SMB is broken due to intel binaries, but i’d have to check.

 

[srp]

What about the permissions issues that are causing most of the double password prompts? educovas' release didn't have any of the issues plaguing this "A5" build.

All of the binaries are stripped, all of the permissions are ruined, all of the timestamps are borked... it is literally impossible to diagnose all of these issues.

IMO the highest priority thing should be an "un-screwed" build that people can actually use and develop on reliably. This script didn't seem to fix anything for me. A post-build patcher to fix a doomed image seems like just bolting on more technical debt. Why not just fix the image?

 

[ChrisCharman]

Feel free to try the script and find out if you like, or create a new image. You could even use another pre-existing image if you’d prefer. Using A5 is not compulsory. We all have lives and busy schedules.

**edit to add;

This is an ongoing work in progress. All builds will contain bugs, now and moving forward. Feedback, patches, fixes all welcomed. Install test builds, updates and other software shared on this thread at your own risk and convenience.

 

[srp]

Feedback, patches, fixes all welcomed.

When your response above reads as "fix it yourself or don't use it", it feels at odds with the idea that feedback is welcome. The reason I'm bringing these things up is because they directly affect usability. The goal should be to make it easier for users to adopt the platform, not to push them towards dual booting or abandoning it.

This build is a regression in many ways from educovas' build and so I think it's perfectly fair to offer feedback about that.

For me, Snow Leopard isn't optional. Many PPCPorts simply don't work on Leopard, and tools like mrustc aren't usable there. Maintaining a Snow Leopard install is necessary now just to use parts of the ecosystem. That's also why the "we all have busy schedules" point cuts both ways. Many users don't have time to fight broken permissions and debug issues caused by a compromised image.

Reducing that friction should be a priority, especially for something that is now being positioned as a base system for development.

If this is an area that just needs more focused effort, and there’s a GitHub repo, change list, or specific areas that need work, I’d be willing to contribute where I can. I think the logical first step is a clean base image with original timestamps and permissions, no base user account, and .AppleSetupDone removed so it kicks you right into the new user experience.

 

[ChrisCharman]

Sounds great, if you have the time and means to do this then by all means go for it. Unfortunately i don’t at the moment, and i’ve not positioned my test A5 build as anything other than a testing build. @barracuda156 does not use that build either, so I’d recommend anyone wanting to run the latest ports and use Snow Leopard as a stable platform for development or personal use should stick to @educovas build with fixes shared in the wiki.

 

[srp]

Sounds great, if you have the time and means to do this then by all means go for it. Unfortunately i don’t at the moment, and i’ve not positioned my test A5 build as anything other than a testing build. @barracuda156 does not use that build either, so I’d recommend anyone wanting to run the latest ports and use Snow Leopard as a stable platform for development or personal use should stick to @educovas build with fixes shared in the wiki.

@barracuda156 links to this thread specifically and your A5 image on https://macos-powerpc.org so it's news to me that he doesn't use that build, lol.

 

[ChrisCharman]

I’ve been mostly inactive and busy with other things, last i was aware @barracuda156 used a specific build made for him that used different drivers for his GPU, but he would know better than me what he’s currently running and why. As i stated, and i do appreciate your frustrations, using A5 is optional and has known bugs. I recommend either trying my script, or using a different build etc.

 

[barracuda156]

@barracuda156 links to this thread specifically and your A5 image on https://macos-powerpc.org so it's news to me that he doesn't use that build, lol.

This is not correct, I do use A5 build, and I use it as my primary system currently. The one with better GL has broken DHCP (I also have it installed, but ports are built on A5).