Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
10.6 Snow Leopard PowerPC Development
- Thread starter ChrisCharman
- WikiPost WikiPost
- Start date
-
- Tags
- poll powerpc snow leopard
- Sort by reaction score
- Status
I restored A5 on my iMac G5 1.8GHz and followed the directions, but my iMac G5 doesn't get beyond the Apple logo (no spinning loading symbol either) before it shuts down. It's also no longer recognizing USB keyboards, so I can't even get into the boot picker to switch back to my Leopard or Tiger partitions. Does anybody have any suggestions on what the cause/fix might be, and how I can get into the boot picker or switch boot partitions without a keyboard?
jktwice
macrumors regular
An apple keyboard is like $5. Spend the money and make your life a little easier. Trust me it is worth it.
Did you try at least with two different keyboards? I have one weird gaming keyboard (someone gave it to me) which did not work for booting to the boot picker.
Smithwick’s
macrumors regular
The fact that it shuts down instead of just going to a kernel panic screen is interesting. I second the above folks in saying you should try it with another keyboard before anything else. Though, if I'm being honest, the symptom of looping and shutting down sounds less like 10.6.8a weirdness and more like capacitor plague. My iMac G5 (an iSight model too, sigh) is out of commission because of a similar issue.
I have tried a few different keyboards on each of the USB ports, including keyboards that worked fine to get into Open Firmware and the boot picker in the past. It could be capacitors, they are all original. It's not iSight though (not that that's much better...) and has been extremely stable on both Tiger and Leopard, at times having over a month of uptime when being used as a server. I wouldn't think it was that.
I have installed on my g5 quad, I have manual setup dns and can not only ping Google, but can ping between my desktops, but I cannot seem to open any webpages... Any ideas?
Which image have you installed?
Have you got another system (10.5, 10a190) on this machine?
I have 10.5.8 on another SSD in the system, yes.
Does it HAVE to be setup in 2 partitions?
I have a 6600 (for now, x1950xt on the way lfg) so I used the nvidia one from macgarden
Unfortunately that one does not have DNS fixed (but has newer GL/CG). You need to a) boot into 10.5.8 and copy Network settings, b) boot into 10.6.8, manually set up Network and then run `sudo /opt/bin/utdns 8.8.8.8` (adjust path as needed). If utdns in missing by default, grab it from here: https://macos-powerpc.org/packages/utdns (or build from source) and place wherever desired (it does not require to be installed via ports).
Ahh, that was what I was going to do, but saw that allegedly some of the releases have that fixed, so I figured that couldn't be my issue haha, if I don't come back presume it's fixed, will reply if I have issues, thanks!!!
@educovas @ChrisCharman Any idea why this happens in A5 image? The error is when building a third party app, but it point to system frameworks:
Code:
cd doc && /usr/bin/make man
cd doc && /usr/bin/make faq
make[1]: Entering directory `/opt/local/var/macports/build/asymptote-d4205772/work/asymptote-3.06/doc'
../asy -dir ../base -config "" -render=0 -h 2>&1 | grep -iv Asymptote > options
make[1]: Entering directory `/opt/local/var/macports/build/asymptote-d4205772/work/asymptote-3.06/doc'
make[1]: `faq' is up to date.
make[1]: Leaving directory `/opt/local/var/macports/build/asymptote-d4205772/work/asymptote-3.06/doc'
Creating asy-keywords.el
./asy -dir base -config "" -render=0 -l > asy.list
dyld: _dyld_bind_fully_image_containing_address() error
dyld: Symbol not found: _ID3ParserClose
Referenced from: /System/Library/PrivateFrameworks/MediaToolbox.framework/Versions/A/MediaToolbox
Expected in: /System/Library/Frameworks/AudioToolbox.framework/Versions/A/AudioToolbox
../asy -dir ../base -config "" -render=0 -f pdf -noprc Bode.asy
/bin/sh: line 1: 89713 Trace/BPT trap ./asy -dir base -config "" -render=0 -l > asy.list
make: *** [asy-keywords.el] Error 133
make: *** Waiting for unfinished jobs....
../asy -dir ../base -config "" -render=0 -f pdf -noprc CAD1.asy
dyld: _dyld_bind_fully_image_containing_address() error
dyld: Symbol not found: _ID3ParserClose
Referenced from: /System/Library/PrivateFrameworks/MediaToolbox.framework/Versions/A/MediaToolbox
Expected in: /System/Library/Frameworks/AudioToolbox.framework/Versions/A/AudioToolbox
dyld: _dyld_bind_fully_image_containing_address() error
dyld: Symbol not found: _ID3ParserClose
Referenced from: /System/Library/PrivateFrameworks/MediaToolbox.framework/Versions/A/MediaToolbox
Expected in: /System/Library/Frameworks/AudioToolbox.framework/Versions/A/AudioToolbox
make[1]: *** [Bode.pdf] Trace/BPT trap
make[1]: *** Waiting for unfinished jobs....
make[1]: *** [CAD1.pdf] Trace/BPT trap
make[1]: Leaving directory `/opt/local/var/macports/build/asymptote-d4205772/work/asymptote-3.06/doc'
make: *** [man] Error 2
I don’t think asymptote invokes a specific symbol. It looks like our MediaToolbox is just broken – and will break anything that links to it.
Has anybody attempted to/succeeded in building Leopard-WebKit (or any newer version of WebKit) on 10.6.8 PPC? I'm going to try to tonight, but it'd be nice to know in advance.
srp
macrumors regular
Why build it from source when you could just test the binary and see what happens?
Smithwick’s
macrumors regular
Because a) we can; b) builds against alien SDK are not optimized.
Having said that, that much old webkit is pointless anyway. And newer ones are broken.
srp
macrumors regular
While we're on this topic, I'd like to offer up some constructive feedback, while also bearing in mind that PPCPorts is your package manager and your development effort so of course it should be up to you to run it however you like. I really appreciate all of your development efforts and part of the reason I can even spin up a dev environment and write apps at all is because of your ports. I just want to offer up my perspective as a Leopard user who has now been using PPCPorts and also working on ports of my own for about ~4ish months.
Leopard is the last first party official PPC Mac OS X release - it should be the primary development operating system. Builds should, as a rule of principle, support Leopard first and be tested on 10.6 for coverage - only requiring 10.6 when a port truly needs it.
There are several reasons this makes more sense than doing it the other way around:
- Snow Leopard is not a stable OS. The A5 build, on top of the networking issues and broken features, lack of sleep etc, also has completely broken permissions causing the bugs with needing to enter a password over and over. There is no clear roadmap or even interested developers who are actively working in this field. Apparently this has been a point of contention in the past with some of the original people working on Snow Leopard who have since walked away from the project? I'm too new to the community to know the story here, but it really doesn't seem like anyone should anticipate these issues being fixed anytime soon.
- I cannot produce a reliable 10.6 targeted binary on 10.5 without 10.6 headers and libs + additional setup, work and testing. I can however compile a 10.5 binary, copy it to a working 10.6 environment, and in most cases it will work just fine.
- Some ports use 10.6-only APIs or assumptions and this is not clearly documented. If you as the maintainer are only testing on 10.6, then Leopard just becomes somebody else's problem, which it already has re: `mrustc`, `qmplay2`. This is an issue that only expands as time goes on and more ports are added/updated without continued development efforts from somebody else. In cases where the port doesn't "just work" on Leopard, the porting work involved is essentially duplicated.
- What happens if the community collectively agrees that sleep (or other major issues) will never be fixed? These ports don't do much good if the OS they're running on is on life support. What happens if gcc14 bugs out with Snow Leopard but not with Leopard? Should we expect Ian Sandoe to invest additional time investigating the differences between the two operating systems, chasing down a bug that doesn't occur in Leopard but only in Snow Leopard (or vice versa?) What are the critical pieces of this puzzle that could break on 10.6, and who will be there to fix them when they do? These are all important questions to consider when deciding "this is the primary intended platform for all of these ports to live on"
I don't really think that the alien SDK thing applies as much as you think it does. The bulk of your performance is coming from HOW you wrote the code in addition to compiler optimizations - the binary just cares about the instructions and libraries it ended up with, and most of the time any differences between the two platforms are not going to make or break performance. It puts a bad taste in my mouth when 10.5 support is declared as a baseline but ports are frequently broken, at the very least, expectations should be set with end users, and it should be emphasized that 10.5 support is "best effort" and that things frequently dont just work as expected.
I understand this is a highly opinionated subject and I hope I don't come across as adversarial. It just sometimes feels like a rock and a hard place when having to choose between a stable platform that many ports may not work for, or getting access to cutting edge ports but having to sacrifice sleep, spend 15 minutes fiddling with DNS every boot, coming home from work to see my PowerBook cooking itself, etc. Snow Leopard is a cool concept but it needs more polish before it should be considered a daily driver OS or a mainline development platform. Hopefully you can understand where I'm coming from.
Dinul-SV
macrumors newbie
I can get it, I just got a G5 Power Mac, so I'm a newbie to many things related to PPC, its quirks or caveats, but I understand that 10.6 (at least in the current state) is pretty unstable and stability is on a tight rope, and your idea to try to target 10.5 as the target, then run on 10.6 is a good idea since Apple introduced it as having "zero new features" (Questionable at a kernel level, but at least we know it's "mostly" true in the userspace). Many of the 10.6-only APIs are Intel-only in later releases and PPC versions are ONLY on very early builds (10A222 with partial support by the kernel, but NOT kexts or the user space), so if we have ANY hope about 10.6-only APIs which are closed-source, it's from 10A96 or 10A190, nothing else.
But if the binary uses 10.6-only APIs, I think I've got an idea (I don't know whether you people would hate it), what if we use "unoptimised" binaries where possible to port, compiled with debug flags, and then, when something messes up, at least we have some more info. Then, if it's stable in that config, remove debug flags and make an "optimised" binary. Time-consuming, sure, but it'd help a lot in fixing broken areas. What I mean here is that, if we can get stack traces of where the ported binary crashes, we can use something like otool or Hopper to find where EXACTLY (or at least relatively) the domino effect of crashing starts at, then it's a matter of patching the cause for the crash without breaking other parts (hopefully).
Last edited:
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.
The kernel we use is the actual 10.6.8 kernel. ppc is fully supported in official kernel. You are correct about some kexts, proprietary components (say, OpenCL or Java) and select proprietary apps (Finder). But likewise, some components of 10.6 which work on ppc cannot be added into 10.5 (or at least no one succeeded). It is a trade-off, that was always clear, I believe.
It is fairly trivial to build in debug mode, MacPorts/PPCPorts support that. In CMake you can set Debug build type. You may explicitly remove optflags and pass `-g` or whatever desired. No changes are required here, anyone can build this way right now.
Appleuser201
macrumors 6502
Leopard Webkit to be quite brutally honest, is hot garbage today. Not sure why anyone uses it except for very basic searches. While it can *technically* still play YouTube, it's gotten pretty bad and is a unwatchable slideshow at 360p on a 1.2ghz iBook. And as for compatibility, it's getting worse by the year and is far behind even the existing TFF based browsers.
Dinul-SV
macrumors newbie
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:
