Snow Leopard on Unsupported PowerPC Macs

[ChrisCharman]

Yes, that was it.

I was able to compile DarwinBuild using MacPorts but I can't build anything because DarwinBuild tries to download stuff from svn.macosforge.org/repository/darwinbuild but it's not available anymore.

There is a way to make DarwinBuild use a local source tree instead of pulling it from the web but i forget exactly the instructions

I'm sure that kexts are going to be a problem since almost no kexts have ppc code on this build and I think that one of the kexts from 10A190 is causing problems on some G4s and possibly G5s.

Yeah almost certainly, some of the kexts are available as source, the hardware specific ones we may as well focus on making the 10.5.8 versions work as the only hardware we care about was fully supported in Leopard. The intel only kexts will need modification though.

 

[educovas]

There is a way to make DarwinBuild use a local source tree instead of pulling it from the web but i forget exactly the instructions

Yeah almost certainly, some of the kexts are available as source, the hardware specific ones we may as well focus on making the 10.5.8 versions work as the only hardware we care about was fully supported in Leopard. The intel only kexts will need modification though.

I'll keep trying to get DarwinBuild to work.

I guess people with G5s and G4s that are different from the one I have, will have to find their own way to resolve these problems since I can't help.

 

[dosdude1]

Does this boot on all G4’s and G5’s? If it only boots on G4’s then that’s not very useful to the project as a whole. I wish I could work on this to help y’all out but I’ve got the Security+ exam today so I apologize.

Completely disagree... G5s are by far the worst and most unreliable PowerPC Macs ever made... Especially the iMac G5. Regardless, though, once we get the desired SL version booting and working as intended on a G4, we can look into the issues with G5s, and more than likely get them working as well.

 

[Edgecrusherr]

Completely disagree... G5s are by far the worst and most unreliable PowerPC Macs ever made... Especially the iMac G5. Regardless, though, once we get the desired SL version booting and working as intended on a G4, we can look into the issues with G5s, and more than likely get them working as well.

There are a lot of really bad G5s out there, but my Late 2005 2.0GHz Dual Core G5 is probably my most reliable computer, in general. It runs more efficiently than my packed-with-upgrades PowerMac G4 Quicksilver, and with all the IO issues I have with Sonoma, I'd say it's even more reliable than my Mac Studio. It has a NV 7800 that I had you flash for me, so it's a go-to to get old workflows done, as well as a decent backup machine when I'm tired of Apple deteriorating software quality.

 

[MacPro2006VBox]

Painstakingly dragged out the only G4 Mac I have… all 50 pounds of it… and am restoring the 10A222 image onto it.

 

[ChrisCharman]

Painstakingly dragged out the only G4 Mac I have… all 50 pounds of it… and am restoring the 10A222 image onto it.

Any testing reported here of 10A096, 10A190, 10A222 or above will be beneficial to all. Even telling us what doesn’t work for you is helpful.

 

[barracuda156]

Did you follow Ssen’s blog instructions? Yeah having DarwinBuild functional would be immensely useful. @barracuda156 didn’t you say that all old ports should still be downloadable? Surely the older, working versions of darwinbuild should still be archived and useable then?

I do not think that MacPorts keep all archaic versions. Also the current darwinbuild port was never built for ppc at all, since 10.5 was stuck with darwinbuild-legacy.

I was able to build darwinbuild for ppc in Rosetta, but did not find it useful. Admittedly, it was quite a while ago and I never put much effort into fixing it.

May be worth trying.

 

[MacPro2006VBox]

Confirmed working on the only G4 I have… the eMac G4 1.25 GHz (USB 2.0)

 

[barracuda156]

Yes, that was it.

I was able to compile DarwinBuild using MacPorts but I can't build anything because DarwinBuild tries to download stuff from svn.macosforge.org/repository/darwinbuild but it's not available anymore.

There was a ticket for that. URLs should be trivially changeable.

 

[barracuda156]

10a222 boots fine on the final model of PB G4 15”. Expected, but just for the record.

 

[MacPro2006VBox]

InterWebPPC working quite nicely… Apple website makes it crash though!

 

[B S Magnet]

10a222 boots fine on the final model of PB G4 15”. Expected, but just for the record.

It’s… almost as if early, internal overtures to continue development of SL with PowerPC support had the final couple of G4 revisions in mind specifically.

There are a lot of really bad G5s out there, but my Late 2005 2.0GHz Dual Core G5 is probably my most reliable computer, in general.

I think what dosdude1 was getting at is the entire system architecture of the G5s was specific and unique to the PPC 970 environment.

In essence, the workarounds were design adaptations needed in order to run properly. For instance, I believe this included at least one additional PPC chip — no longer remember if it was a PPC 4xx or another — to, more or less, bootstrap the rest of the system during early start-up, either at or just after POST.

So it would lend that ironing out the G4-related issues with these new build adaptations we’re managing to run would need smoothing first before isolating additional boot requirements specific to G5 architecture — especially from 10A222 onward.

 

[MacPro2006VBox]

It’s… almost as if early, internal overtures to continue development of SL with PowerPC support had the final couple of G4 revisions in mind specifically.



I think what dosdude1 was getting at is the entire system architecture of the G5s was specific and unique to the PPC 970 environment.

In essence, the workarounds were design adaptations needed in order to run properly. For instance, I believe this included at least one additional PPC chip — no longer remember if it was a PPC 4xx or another — to, more or less, bootstrap the rest of the system during early start-up, either at or just after POST.

So it would lend that ironing out the G4-related issues with these new build adaptations we’re managing to run would need smoothing first before isolating additional boot requirements specific to G5 architecture — especially from 10A222 onward.

I mean my eMac even boots it…

 

[barracuda156]

the hardware specific ones we may as well focus on making the 10.5.8 versions work as the only hardware we care about was fully supported in Leopard.

Not really. USB3 not supported in Leopard, TB not supported, AHCI support only a bit.

(I have no idea if it is feasible to fix via kexts though.)

 

[barracuda156]

Completely disagree... G5s are by far the worst and most unreliable PowerPC Macs ever made... Especially the iMac G5. Regardless, though, once we get the desired SL version booting and working as intended on a G4, we can look into the issues with G5s, and more than likely get them working as well.

I have had iMac G5 back in the day and had no complaints, it worked fine. I have two PowerMacs G5 now, and everything work fine too.

Reliability issues are vastly exaggerated based on some anecdotal evidence, IMO. Performance-wise no G4 comes close, and only G5 remains usable for development.

 

[B S Magnet]

Not really. USB3 not supported in Leopard, TB not supported, AHCI support only a bit.

Not a surprise, as USB3 support didn’t arise until USB3-equipped Macs appeared for sale in 2012 (around the time Mountain Lion was being readied for release), and Thunderbolt didn’t arise until very late in Snow Leopard’s release cycle (i.e., 10.6.6 [10J3210] and later).

(I have no idea if it is feasible to fix via kexts though.)

Unless there’s some way to obtain source code for proprietary elements to build a kext for specific hardware back-support to big-endian PowerPC architecture, then I’m guessing not.

 

[ChrisCharman]

I do not think that MacPorts keep all archaic versions. Also the current darwinbuild port was never built for ppc at all, since 10.5 was stuck with darwinbuild-legacy.

I was able to build darwinbuild for ppc in Rosetta, but did not find it useful. Admittedly, it was quite a while ago and I never put much effort into fixing it.

May be worth trying.

I find it unlikely that there was only ever a broken port of DarwindBuild available, and also it was at one point PPC compatible as the only macs in existence were PowerPC systems. If it’s not fixable via MacPorts we’ll have to look at building it locally from source then.

Not really. USB3 not supported in Leopard, TB not supported, AHCI support only a bit.

(I have no idea if it is feasible to fix via kexts though.)

I wasn’t referring to hardware kexts that are irrelevant to the PowerPC sku’s, I mean that the hardware kexts and IOKit drivers we need already exist in 10.5, we just need to make them work on later builds of Snow Leopard. Essential system kexts are available as source, which are the ones i refer to as needing to potentially be modified - everything else we can take from Leopard as we have been doing. If anyone wants to write new kexts for USB3 et al then that is also possible but would require a lot of work, but certainly not impossible.

I have had iMac G5 back in the day and had no complaints, it worked fine. I have two PowerMacs G5 now, and everything work fine too.

Reliability issues are vastly exaggerated based on some anecdotal evidence, IMO. Performance-wise no G4 comes close, and only G5 remains usable for development.

I disagree that G4 is useless for development. Most of the people in this subforum are specifically using older PowerPC macs, and ruling them out because they’re slower than G5 seems to go against the point of this vintage mac thread. If you mean you have a more forward outlook and would prefer to focus on developing macports ‘ports’ and later versions of software for G5 only then that’s understandable, but keep in mind that the userbase for G5 systems is considerably smaller than the already small base of PowerPC mac users as a whole.

Not a surprise, as USB3 support didn’t arise until USB3-equipped Macs appeared for sale in 2012 (around the time Mountain Lion was being readied for release), and Thunderbolt didn’t arise until very late in Snow Leopard’s release cycle (i.e., 10.6.6 [10J3210] and later).



Unless there’s some way to obtain source code for proprietary elements to build a kext for specific hardware back-support to big-endian PowerPC architecture, then I’m guessing not.

Exactly. Hardware support beyond what is supported in Leopard is unnecessary, we just need to build the new kernels against the older kexts, ignore any non-relevant intel only kexts and potentially rebuild the available and relevant IOKit drivers and kexts where needed, and available.

The focus should continue to be on the OS itself at this point, in my opinion, and not adding additional unnecessary complexity. We will only ever have a hybrid system without backwards engineering the proprietary components, and that’s fine with me, we just need to integrate the most recent compatible components where we’re able.

 

[barracuda156]

Unless there’s some way to obtain source code for proprietary elements to build a kext for specific hardware back-support to big-endian PowerPC architecture, then I’m guessing not.

PowerPC BE as such should not be an issue, since I am sure at least some Linux or BSD support those. Whether drivers are portable is a different question.

 

[ChrisCharman]

PowerPC BE as such should not be an issue, since I am sure at least some Linux or BSD support those. Whether drivers are portable is a different question.

There’s Apple documentation on porting from BSD to Mac OS. The BSD portion of OS X is similar but different enough that some modifications are required for portability.

Overview of OS X

Conceptual information and tips about porting UNIX and Linux applications to OS X.

developer.apple.com

 

[barracuda156]

I find it unlikely that there was only ever a broken port of DarwindBuild available, and also it was at one point PPC compatible as the only macs in existence were PowerPC systems. If it’s not fixable via MacPorts we’ll have to look at building it locally from source then.

What is currently darwinbuild in Macports never existed for ppc, and apparently never has been built, forget tested, for ppc by its upstream either. This is because it was redesigned with 10.6 in mind, and 10.6 ppc was not accessible or considered.

There is darwinbuild-legacy which should have worked on 10.5 ppc at some point, of course. But it is useless for us even if it was working now, since it does not build anything beyond 10.5. Last time I tried it did not even build.

Anything that can be fixed and built outside of MacPorts can be done inside MacPorts as well. The only question is what is easier and whether having something in MacPorts brings extra benefit or not.
In a case of DarwinBuild, I think, there is no extra benefit, since it is meant to build system components only, and MacPorts does not need such a tool and normally is not used to build system components (though it is possible to use MacPorts for that aim).
Whether it is easier to fix it via MacPorts or not, I have no idea at the moment.

I disagree that G4 is useless for development. Most of the people in this subforum are specifically using older PowerPC macs, and ruling them out because they’re slower than G5 seems to go against the point of this vintage mac thread. If you mean you have a more forward outlook and would prefer to focus on developing macports ‘ports’ and later versions of software for G5 only then that’s understandable, but keep in mind that the userbase for G5 systems is considerably smaller than the already small base of PowerPC mac users as a whole.

Ok, to make it sound less controversial, I can say development aside of fixing the OS itself.

However, using G5 does not exclude G4. To the contrary, on G5 you can do much more meaningful work for usage on G4 than on G4 natively. And we do not need to consider some obscure MacPorts stuff or even MacPorts at all.
A build of gcc takes around 3–4 hours on G5. With modula and rust it will be somewhat longer. With tests it will be considerably longer. On G4 it will take, like, a week? 🙂 This is still doable, but nobody gonna actually do it on a regular basis. No G5 = no compilers development for G4.

 

[ChrisCharman]

What is currently darwinbuild in Macports never existed for ppc, and apparently never has been built, forget tested, for ppc by its upstream either. This is because it was redesigned with 10.6 in mind, and 10.6 ppc was not accessible or considered.

There is darwinbuild-legacy which should have worked on 10.5 ppc at some point, of course. But it is useless for us even if it was working now, since it does not build anything beyond 10.5. Last time I tried it did not even build.

Anything that can be fixed and built outside of MacPorts can be done inside MacPorts as well. The only question is what is easier and whether having something in MacPorts brings extra benefit or not.
In a case of DarwinBuild, I think, there is no extra benefit, since it is meant to build system components only, and MacPorts does not need such a tool and normally is not used to build system components (though it is possible to use MacPorts for that aim).
Whether it is easier to fix it via MacPorts or not, I have no idea at the moment.



Ok, to make it sound less controversial, I can say development aside of fixing the OS itself.

However, using G5 does not exclude G4. To the contrary, on G5 you can do much more meaningful work for usage on G4 than on G4 natively. And we do not need to consider some obscure MacPorts stuff or even MacPorts at all.
A build of gcc takes around 3–4 hours on G5. With modula and rust it will be somewhat longer. With tests it will be considerably longer. On G4 it will take, like, a week? 🙂 This is still doable, but nobody gonna actually do it on a regular basis. No G5 = no compilers development for G4.

DarwinBuild for 10.6 source is what we need, and DarwinBuild Legacy for PowerPC compatibility. Even getting a Snow Leopard version running on intel would be useful as we could cross compile from a Snow Leopard compatible machine.

When building system components, only older specific versions of the compilers should be used anyway so it’s not really an issue for me. As G5 should be able to run a properly G4 compatible build of 10AXXX there’s really no need to focus on specific G5 optimisations or adaptations, and any modifications targeting G5 specifically will not be backwards compatible with G4. As the G5 support never existed, this will need to be added which is a lot more work than improving the level of G4 compatibility that we already have.

As the person with the most experience with MacPorts on 10A190, you are best qualified to understand if MacPorts is useful for building system components for this project @barracuda156. So far, i’ve only found building directly from the command line and in Xcode to be viable.

With regard to compiler and third party development for the platform, this really isn’t an expectation. We are a minority userbase and our vintage hardware will not gain mass support. Any development will continue to be a labour of love for those that choose to spend how ever much time they are willing supporting PowerPC, Snow Leopard or not.

 

[barracuda156]

DarwinBuild for 10.6 source is what we need, and DarwinBuild Legacy for PowerPC compatibility. Even getting a Snow Leopard version running on intel would be useful as we could cross compile from a Snow Leopard compatible machine.

Well, such DarwinBuild does not exist, LOL.
We should either fix legacy version and teach it to build 10.6 sources or add support for ppc into a 10.6-compatible version. I think the second makes a better sense, but it is just a guess.

As the person with the most experience with MacPorts on 10A190, you are best qualified to understand if MacPorts is useful for building system components for this project @barracuda156. So far, i’ve only found building directly from the command line and in Xcode to be viable.

This is not a theoretical question, I have ports to build libdispatch and libcxx for PowerPC, which are system components. An earlier, makefiles-based port of libcxx for Intel also is there, and can be used to build that version for ppc with some tweaks to the portfile and patches (but why we need an earlier version anyway).
After all, MacPorts is just a build system. You can use it to build anything, though for some stuff it may not be an optimal solution, obviously. (For example, cross-compiling is not supported presently, and supporting it would require a lot of work, I think.)

 

[ChrisCharman]

Well, such DarwinBuild does not exist, LOL.
We should either fix legacy version and teach it to build 10.6 sources or add support for ppc into a 10.6-compatible version. I think the second makes a better sense, but it is just a guess.



This is not a theoretical question, I have ports to build libdispatch and libcxx for PowerPC, which are system components. An earlier, makefiles-based port of libcxx for Intel also is there, and can be used to build that version for ppc with some tweaks to the portfile and patches (but why we need an earlier version anyway).
After all, MacPorts is just a build system. You can use it to build anything, though for some stuff it may not be an optimal solution, obviously. (For example, cross-compiling is not supported presently, and supporting it would require a lot of work, I think.)

Precisely what i was suggesting regarding DarwinBuild.

No it’s not a theoretical question. It is encouragement for you to test the system components you’ve built via MacPorts as actual replacements for the system and report findings as you’re best positioned to do this.

 

[barracuda156]

Precisely what i was suggesting regarding DarwinBuild.

By the way, there is perhaps a reproducible way to get darwinbuild(-legacy) to build and work on 10.5 (assuming that is of interest): check out to a git commit around that time (GH history will have it), use that repo as an overlay, temporarily, and sudo port -v install darwinbuild / darwinbuild-legacy. (Here by darwinbuild I mean what is now -legacy, but it became such after the 10.6 version was introduced, so you could also use an earlier commit.)
Since 10.5.8 and its Xcode did not change ever since, that should either work or, well, gonna prove it was broken from the outset.

It should actually require little, since it does not have many dependencies and should not need C++11, so Xcode gcc will do. If you try, make sure to have default settings for Macports (again, temporarily).

 

[ChrisCharman]

By the way, there is perhaps a reproducible way to get darwinbuild(-legacy) to build and work on 10.5 (assuming that is of interest): check out to a git commit around that time (GH history will have it), use that repo as an overlay, temporarily, and sudo port -v install darwinbuild / darwinbuild-legacy. (Here by darwinbuild I mean what is now -legacy, but it became such after the 10.6 version was introduced, so you could also use an earlier commit.)
Since 10.5.8 and its Xcode did not change ever since, that should either work or, well, gonna prove it was broken from the outset.

It should actually require little, since it does not have many dependencies and should not need C++11, so Xcode gcc will do. If you try, make sure to have default settings for Macports (again, temporarily).

I’m at work today and then away from home over the weekend but i may try this out at some point in the future.