If you will try rebuilding Libc, we need to try if this works: https://raw.githubusercontent.com/m...es/pthread_threadid_np-expose-on-PowerPC.diff
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.
Snow Leopard on Unsupported PowerPC Macs
- Thread starter Larsvonhier
- WikiPost WikiPost
- Start date
- Sort by reaction score
- Status
If you will try rebuilding Libc, we need to try if this works: https://raw.githubusercontent.com/m...es/pthread_threadid_np-expose-on-PowerPC.diff
I don't think that will be necessary since all libs in /usr/lib are already compiled for ppc on this build (and every Snow Leopard build for what I could see).
This symbol is not available for ppc even in 10.6.8. Look at the code, it is the Libc of 10.6.8. Can also be checked via nm -arch ppc -g /usr/lib/libSystem.B.dylib | grep ${symbol}, if I remember correctly.
This breaks Python 3.12, for example, and all other software which uses this symbol (and expects it to be present in 10.6).
UPD. Exact links to the sources: https://github.com/apple-oss-distri...088b4db8668f40/pthreads/pthread.c#L1121-L1149
Libc/pthreads/pthread.h at 7380dc7cf0fc04550c72f34d38088b4db8668f40 · apple-oss-distributions/Libc
Contribute to apple-oss-distributions/Libc development by creating an account on GitHub.
github.com
Last edited:
Oh ok, a job for the future since I still have a lot of work to do to hopefully get 10.6.8 running on PPC. Or maybe someone else might want to do it.
Snow Leopard and even Yosemite came with Python 2.7!
If one wants to recreate SL for PPC as it was probably intended by Apple, it would be wise not to include custom variables, such as Python 3.
I am late to this sidebar, and I have written about this previously, including in this very thread.
The point of the all-Intel transition, from Apple’s vantage in 2009, was that the literal transition would be smooth, nearly seamless, and not obvious to most people using their Macs the previous day in 10.5.8, just before installing the retail 10.6.
The notion of making sure the fundamental coding changes (to all-Intel, all-Cocoa, etc.) didn’t freak out end users was sort of the underlying point of Snow Leopard: to deliver the familiar experience of Leopard without anything being visually jarring or completely different in the way people could do their productivity. The transition’s chief, front-facing goal was to not freak anyone out.
The last thing Apple wanted then — or with Serlet overseeing it — was to usher a completely different experience alongside the news that all the PowerPC Macs had just been left behind. In this sense, they succeeded from 10.6.0, forward.
He has left MR forums and has been gone for a couple of years.
In addition, z970 was never involved with the A Clouded Leopard project. What he did, however, was throw popcorn at those of us who were involved. Between posts #757 and 763, I firmly asked him to either roll up his sleeves and get dirty in the work like the rest of us, or to stick with his pet projects.
He chose the latter, as was his wont.
I don’t devalue the work.
I did (and always will) question how virtually every “refinement” he incorporated into his “Sorbet Leopard” were all the fixes this community had discovered without his involvement (nearly all of them contained within The Leopard Thread, and its wikipost).
What he didn’t do was to give attribution to those efforts before his time (even if he wasn’t required to give attribution). This speaks a lot about an individual’s perspective on the value of community versus the solitary satisfaction of presenting a thing as if it was their own invention. (We all stand on the shoulders of those before us, and to pretend we don’t is never a good look).
The final thing to have left a bad aftertaste for MR PPC forum regulars was the gumption to cos-market (like “cosplay”) Sorbet Leopard as if it was something Apple actually flirted with in a fever dream of his — down to using Apple’s then-branding style guide to make it look as if all these efforts done by the community were not only his work, but also something a fantasy-Apple from his fever dreams might green-light.
Correct. See posts #757 to 763.
As noted above, z970 never worked on A Clouded Leopard. He also didn’t come up with most of the “Sorbet Leopard” individual tweaks himself, either.
He used components which others figured out, and he didn’t give attribution to those parties. No one forced his hand to give attribution.
When one volunteers to give attribution, then it’s a sign of respect for the community to have made it possible.
When one volunteers not to, then one is acting in the sole service of oneself, aspiring to bask in whatever positive feedback and accolades to follow.
The decision to give (or deprive) attribution to an all-volunteer community of folks who, selflessly, donate their time and knowledge speaks to the integrity (or lack thereof) of one’s character.
z970 left because he faced enough people here who questioned his lack of integrity. He left voluntarily. He can still work on projects, and fans of his projects can still use them. But fans also deserve to understand why his conduct with cribbing other people’s works without giving them a nod was divisive to begin with.
The point of the all-Intel transition, from Apple’s vantage in 2009, was that the literal transition would be smooth, nearly seamless, and not obvious to most people using their Macs the previous day in 10.5.8, just before installing the retail 10.6.
The notion of making sure the fundamental coding changes (to all-Intel, all-Cocoa, etc.) didn’t freak out end users was sort of the underlying point of Snow Leopard: to deliver the familiar experience of Leopard without anything being visually jarring or completely different in the way people could do their productivity. The transition’s chief, front-facing goal was to not freak anyone out.
The last thing Apple wanted then — or with Serlet overseeing it — was to usher a completely different experience alongside the news that all the PowerPC Macs had just been left behind. In this sense, they succeeded from 10.6.0, forward.
He has left MR forums and has been gone for a couple of years.
In addition, z970 was never involved with the A Clouded Leopard project. What he did, however, was throw popcorn at those of us who were involved. Between posts #757 and 763, I firmly asked him to either roll up his sleeves and get dirty in the work like the rest of us, or to stick with his pet projects.
He chose the latter, as was his wont.
I don’t devalue the work.
I did (and always will) question how virtually every “refinement” he incorporated into his “Sorbet Leopard” were all the fixes this community had discovered without his involvement (nearly all of them contained within The Leopard Thread, and its wikipost).
What he didn’t do was to give attribution to those efforts before his time (even if he wasn’t required to give attribution). This speaks a lot about an individual’s perspective on the value of community versus the solitary satisfaction of presenting a thing as if it was their own invention. (We all stand on the shoulders of those before us, and to pretend we don’t is never a good look).
The final thing to have left a bad aftertaste for MR PPC forum regulars was the gumption to cos-market (like “cosplay”) Sorbet Leopard as if it was something Apple actually flirted with in a fever dream of his — down to using Apple’s then-branding style guide to make it look as if all these efforts done by the community were not only his work, but also something a fantasy-Apple from his fever dreams might green-light.
Correct. See posts #757 to 763.
As noted above, z970 never worked on A Clouded Leopard. He also didn’t come up with most of the “Sorbet Leopard” individual tweaks himself, either.
He used components which others figured out, and he didn’t give attribution to those parties. No one forced his hand to give attribution.
When one volunteers to give attribution, then it’s a sign of respect for the community to have made it possible.
When one volunteers not to, then one is acting in the sole service of oneself, aspiring to bask in whatever positive feedback and accolades to follow.
The decision to give (or deprive) attribution to an all-volunteer community of folks who, selflessly, donate their time and knowledge speaks to the integrity (or lack thereof) of one’s character.
z970 left because he faced enough people here who questioned his lack of integrity. He left voluntarily. He can still work on projects, and fans of his projects can still use them. But fans also deserve to understand why his conduct with cribbing other people’s works without giving them a nod was divisive to begin with.
Do you even read? )
No one suggested to replace system Python. I point out that Apple deliberately broken something specifically for PowerPC in its Libc in 10.6. And it is desirable to fix it, because everything else expects that to work, as it does on x86.
P. S. The overall goal is to make 10.6 ppc as close to 10.6.8 x86 as possible in every regard, because that is what Apple designed (but leaving ppc out) and that is what third-party software expects to have available. When such an expectation fails, bad things happen. Some of those are easily fixable, but it required time and effort on every such occasion, some are non-trivial to fix or result in sub-optimal results.
Last edited:
I merely mentioned that just in case. I can probably deal with Libc, as you sort out the xnu.
Personally i’m in total agreement with this sentiment. I’ve been trying in all of my attempts to replicate, or at least get as close to, 10A432 as possible. This is why i haven’t experimented with any 3rd party ports or packaging systems, and have consistently recommended sticking to version numbers (even for compilers) and tools used in the GM, and where feasible by Apple during the development process. @educovas has made massive strives forward in this regard in recent weeks.
It’s very easy to miss the relevance of and the significance of large codebase changes, deprecation, implementation and ‘optimisation’ differences and so on, across different versions of the same software, that can have a massive impact on system stability, reliability and ease of debugging. Minimising variables at this stage is essential.
What @barracuda156 has been working on all along, is future focused and with a view to creating a platform for further development on PowerPC OS X. His work on getting MacPorts running on the developer previews, with the help of others, and on seeking fixes and fixing broken ports for us to use is certainly valuable. He is also met with resistance consistently when approaching the MacPorts community as they are often unwilling to support obsolete and buggy software used only by a handful of people on this thread, his efforts have been consistent and clearly aimed at ensuring as much modern software is available for PowerPC as possible, within his own ability to do so, which is admirable.
It is however a separate goal to the main aim of this thread which, as you correctly stated, is creating a version of Snow Leopard that is as close to the retail release enjoyed and adored by intel mac users in its time, as is possible.
The other aim of this thread (equally as important) is to document the differences between all of the builds that we find and gain a better understanding of the development of OS X 10.6 as well as archiving said builds. @B S Magnet has unarguably contributed the most in this endeavour and is always striving to make things clear, accessible and reproducible for current and future readers and users. @B S Magnet has also tested, modified and lived with build 10A096 more than anyone else that i’m aware of in the community.
@barracuda156 was encouraged to create separate threads to chronicle his work on MacPorts and 3rd party PowerPC software development which is where most of these findings and updates reside. As one of the more regular and most active testers and users of 10A190 however, often there is crossover where @barracuda156 feels it is relevant. This is, of course, a subjective viewpoint and sometimes causes confusion as it doesn’t always relate directly to the goals of the thread in the short term, and can sometimes make the thread difficult to follow - a fine line to walk.
Last edited:
Let me reiterate: what I said above is exactly getting 10.6 closer to 10.6.x releases. In the current Libc that symbol exists, but is removed specifically for ppc. Making it available gonna make 10.6 closer to 10.6.8 on Intel.
There were no suggestions made to replace system Python or whichever OS components with something newer than those of 10.6.8.
I think the point that’s being missed is that Snow Leopard itself doesn’t require a later version of Python. It only matters if your goal is to run current software, or at least software released later than Snow Leopard, therefore is not currently a priority as we’re still trying to get a fully functioning OS. That’s all. Nobody is objecting to you pursuing this yourself.
@barracuda156 have you had a chance to test any of your system components built using MacPorts as replacements yet? Did they work as well as those compiled on the command line?
If we agree regarding bringing 10.6 ppc as much close as possible to 10.6.8 x86 being desirable, it should be completely irrelevant what somebody uses this or that functionality for.
I referred to Python simply because expected it to be a known and uncontroversial thing (okay, it turned out to be controversial, I was wrong). But if one wants to run software which was written for 10.6, especially without relying on MacPorts, this is likely to matter to have 10.6 behave as 10.6.
P. S. First page here has a list of apps which fail to run on 10.6 ppc. That happens because of SDK differences. Given that someone here cared to try running those apps, using software on the OS still matters.
Last edited:
I did not stick anything directly into the system (and do not advise doing that at the moment), but I did verify that several apps can build against libdispatch-legacy and work and I built a simple app against libc++ (libcxx-powerpc) and confirmed it does what it should.
This does not on its own mean that these are “production-ready”, of course; libdispatch may need something from Libc which could be missing in 10.6 ppc at the moment (and that may not show up in some scenario but will show up elsewhere), and libc++ has not been tested for ppc by anyone, AFAIK.
So yes, they are shown to work in a few narrow scenarios, but likely require further work.
You’re not wrong @barracuda156 and what you’re suggesting isn’t controversial at all, and I understand that Python is an example that you were using to demonstrate that there is work to be done to enable third party software to run. Those of us that look forward to using Snow Leopard as a Leopard replacement will want 3rd party software, obviously.
It just seems pertinent to point out that, given that there are so few of us working on this, and given that most people wanting to run SLPPC as a daily driver will not be satisfied until there is a single, stable ‘finalised’ build available, that trying to fix third party app support is not a primary objective at this point in time.
What I’m trying to say is that if the base system is in constant flux, due to the nature of trial and error development, then spending time on 3rd party software compatibility on intermittent builds only to later find that the work needs to be done again on later builds due to internal changes, or adding additional complexity and instability to the system causes additional errors within the OS itself when there are already bugs and errors that need to be addressed, just seems unnecessary and unwise at this point in time.
The focus should be, in my opinion, to get the OS itself working properly first, and then once we’re all using the same stable ‘close as we can get to 10A432 GM build’ as possible move on to 3rd party software compatibility for the platform as there will be fewer under the hood changes to contend with, and we’ll all be on the ‘same page’. That means working on OS functionality first and foremost.
This is very interesting, good work @barracuda156. I would still be interested to know if we can use your MacPorts as a build system, as it would enable less tech savvy people to contribute and reduce compile time for the few of us spending computer cycles on this.
It seems I am being misread. It is not that a bug in Libc should be fixed because some third-party app needs that to run correctly; it is desirable to fix it, because it is a bug, and because it makes behavior of 10.6 ppc deviate from the standard 10.6 release. Nowhere here the focus is going away from the OS itself.
Also, quite clearly, this is a relatively minor issue, which I hope I made explicit. It is not to be prioritized over something else, but yes, it makes sense to have it in mind whenever someone starts working on Libc. Nothing more than that.
Yeah I think maybe your examples are what have caused confusion. Eventually LibC will need to be rebuilt anyway as LibSystemB.dylib contains the C libraries for OS X. I’m not aware of any current issues that are being caused by the different version of the library though.
That’s great @barracuda156! Will make it much easier for normal users
UI mostly fixed, got all apps from older build and applied the 10.6.1(10B504) update which is a pretty small update and still very similar to GM(10A432).
I'm currently struggling with WiFi and Bluetooth. WiFi connects but can't access the internet (Self-Assigned IP error).
I hope I can fix WiFi soon so I can image the install and share here.
This will make it easier for myself as well, LOL.
Instead of 10+ hrs of compilation to get to gcc13 on a new machine (and forever on G4) it will be a few minutes.
I will need someone to test it once I release the thing. Hopefully someone here, since nobody else has 10.6 ppc
I will add instructions how to build everything from source too, in a case someone does not want to use a pkg.