Snow Leopard on Unsupported PowerPC Macs

[educovas]

That’s interesting. Disk utility is very buggy in 10A190 but appears to work in your 10A222 build - i imagine it’s something replaced in /usr/bin that’s fixed the errors as the source for the disk management stuff was something i was working through a while back and some binaries were intel only.

How exactly did you manage to swap the Finder? I think this was attempted by at least one other contributor early on in this project to some success but hasn’t been repeated since - i was certainly presented with a non-functional desktop when i tried if memory serves. It’s also interesting that the 10.5.8 Finder is being used because the bug with mounting and ejecting disks still presents itself.

The reason why I'm using Finder from 10.5.8 was due to a crash related to the QuartzCore also from 10.5.8 that I couldn't find a proper fix. After replacing Finder it did not work but you can easily see why if you launch Finder through terminal. It was mostly due to changes in QuickLook, I had to also swap and add a framework that was removed in 10A190.

I've been trying to find what's causing the mounting/ejecting bug but no luck so far.

 

[barracuda156]

@educovas Disk Utility appears to be functional on your build of 10A222, did you replace it? Also which version of Finder is being used?

What’s wrong with Disk Utility? It works in 10a190 too.

 

[barracuda156]

Most apps in /Applications lost ppc support and I've replaced with 10A190, except DVD Player that's from 10.5.8 because the one in 10A190 seems to be unstable (at least on my machine).

Finder is from 10.5.8, I could have used the one from 10A190 but I had to use 10.5.8 due to some problems with my QE/CI patch.

Finder in 10a190 has a bunch of bugs. While usable, it is not pleasant. So perhaps either 10.5.8 one or possibly 10a96 one is a better pick.

 

[ojfd]

That’s interesting. Disk utility is very buggy in 10A190 but appears to work in your 10A222 build - i imagine it’s something replaced in /usr/bin that’s fixed the errors as the source for the disk management stuff was something i was working through a while back and some binaries were intel only.

Speaking of Disk Utility.. Slow permission repairs were getting on my nerves in 10.5.8, so I tried to move 10A96 and 10A190 Disk Utility and its parts to Leopard. It turns out, the contents of /usr/bin related to Disk Utility are different in 10A96 and 10A190.

10A96 has diskutil + diskutilR
10A190 has diskutil + diskutilL

10A96 didn't work in 10.5.8, but when I started 10A190, the alert popped up "Repair permissions is not implemented yet, use legacy version" (or something to that extent).


EDIT. I also finally find out why Disk Utility is so slow in 10.5.8, but that's OT here.

 

[B S Magnet]

Speaking of Disk Utility.. Slow permission repairs were getting on my nerves in 10.5.8, so I tried to move 10A96 and 10A190 Disk Utility and its parts to Leopard. It turns out, the contents of /usr/bin related to Disk Utility are different in 10A96 and 10A190.

10A96 has diskutil + diskutilR
10A190 has diskutil + diskutilL

10A96 didn't work in 10.5.8, but when I started 10A190, the alert popped up "Repair permissions is not implemented yet, use legacy version" (or something to that extent).


EDIT. I also finally find out why Disk Utility is so slow in 10.5.8, but that's OT here.

This is interesting to know, thank you.

Testing and comparing of binaries in /usr/bin/, /usr/sbin, etc. were the stage at which I paused my own testing, as I had no quick and dirty way to compare version differences between binaries in builds like 10A96, 10A190, and 10.5.8.

I was aware many binaries get invoked by system applications (.app) and prefPanes (as we learnt early during the fixing of the PrintAndFax.prefPane functionality).

But without a rapid means for me to do side-by-side analysis of which binaries got invoked by an application, which binaries were changed from build to build, and so on, the workload got too burdensome to continue at the pace I’d been doing testing. It’s what stopped my omnibus-like installer-updater for 10A96 — to be run promptly after a fresh install of 10A96, to dovetail in all fixes from project testing with one updater.

This is still a sticking point for me. Using, say, diff wasn’t sufficient beyond “these binaries have different byte counts/touch dates”.

tl;dr: thanks for figuring out how to get Disk Utility working with the 10A190 application and binary dependencies.

 

[ojfd]

You might try this app to check for dependencies: https://github.com/kwin/macdependency I use it all the time.
There are three different compiled versions available. On PPC use v.0.5. Although v.1.0 is UB, it crashes on my 10.5.8

 

[MacPro2006VBox]

Yes, but aren’t you in, like, Russia?

Ohio

 

[barracuda156]

You might try this app to check for dependencies: https://github.com/kwin/macdependency I use it all the time.
There are three different compiled versions available. On PPC use v.0.5. Although v.1.0 is UB, it crashes on my 10.5.8

It was reported earlier to the developer, and solution was to break the build completely: https://github.com/kwin/macdependency/issues/3

 

[B S Magnet]

Ohio

I mean…

 

[barracuda156]

In a matter of couple of days I think I will have an archive site running, so hopefully MacPorts will be a breeze – provided you trust my packages )
(There is some 40 GB of ppc software, so uploading takes time.)

I will also make archives of ports, so it will not be needed to suffer with cloning via git or manual patching.

There will be a few pre-built ports for Tiger, but as such only 10.6 ppc will be supported. (10.5 will be added only if I get ppc64 working properly. 10.4 will not be supported, by I try to get major stuff built, without any commitment to maintenance.)

 

[ChrisCharman]

What’s wrong with Disk Utility? It works in 10a190 too.

Repairing permissions and verification of disks is buggy mate, unless using the command line and that applies to intel and ppc as noted in the official seed notes

 

[ChrisCharman]

Not satisfied with the uncertainty that my earlier findings were 100% accurate I have checked again now that I can boot into a working 10A222 installation and can confirm that 10A190 and 10A222 both use the same version of LibSystem.B.dylib and distinctly different than 10.5.8, 10A096 and every build after 10A222. All version numbers included in my post earlier in the thread.

For reference here are the different LibSystem and LibmathCommon versions across builds:

LibSystem.B.dylib - Mach-O dynamically linked shared library - Universal


10.5.8:


/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.1.7)


/usr/lib/system/libmathCommon.A.dylib (compatibility version 1.0.0, current version 292.4.0)


10A096:


/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 114.0.0)


/usr/lib/system/libmathCommon.A.dylib (compatibility version 1.0.0, current version 301.0.0)


10A190:

/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 117.0.0)


/usr/lib/system/libmathCommon.A.dylib (compatibility version 1.0.0, current version 302.0.0)


10A222:

/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 117.0.0)


/usr/lib/system/libmathCommon.A.dylib (compatibility version 1.0.0, current version 302.0.0)


10A261:


/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 119.0.0)


/usr/lib/system/libmathCommon.A.dylib (compatibility version 1.0.0, current version 306.0.0)


10A354:

/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 123.0.0)


/usr/lib/system/libmathCommon.A.dylib (compatibility version 1.0.0, current version 313.0.0)


10A380:

/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 123.0.0)


/usr/lib/system/libmathCommon.A.dylib (compatibility version 1.0.0, current version 314.0.0)


10A432:

/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.0.1)


/usr/lib/system/libmathCommon.A.dylib (compatibility version 1.0.0, current version 315.0.0)

 

[barracuda156]

Repairing permissions and verification of disks is buggy mate, unless using the command line and that applies to intel and ppc as noted in the official seed notes

Yes, you are right, I just did not think of that.

 

[barracuda156]

View attachment 2376004 View attachment 2376003 Not satisfied with the uncertainty that my earlier findings were 100% accurate I have checked again now that I can boot into a working 10A222 installation and can confirm that 10A190 and 10A222 both use the same version of LibSystem.B.dylib and distinctly different than 10.5.8, 10A096 and every build after 10A222. All version numbers included in my post earlier in the thread.

A good thing is that pretty much everything built for 10a190 should work fine on 10a222, but also all bugs we have in libSystem are still there.

 

[educovas]

Build 10A432(GM) boots successfully into single user mode after building a custom kernel and restoring the removed ppc binaries.

There was no need to replace anything in the xnu source, just delete and adjust some stuff that's in the attached text file. I still don't know if this kernel works 100% but seems ok so far.

 

[ChrisCharman]

View attachment 2376010

Build 10A432(GM) boots successfully into single user mode after building a custom kernel and restoring the removed ppc binaries.

There was no need to replace anything in the xnu source, just delete and adjust some stuff that's in the attached text file. I still don't know if this kernel works 100% but seems ok so far.

Excellent @educovas! Did you build this using DarwinBuild on Snow Leopard or from the command line?

 

[internetzel]

View attachment 2376010

Build 10A432(GM) boots successfully into single user mode after building a custom kernel and restoring the removed ppc binaries.

There was no need to replace anything in the xnu source, just delete and adjust some stuff that's in the attached text file. I still don't know if this kernel works 100% but seems ok so far.

That's really great!
I searched my backups and old hard drives and did find the darwinbuild buildroot directory where I had the sources of xnu from 10.5.8 and 10.6.2 in a 9L30 buildroot. Unfortunately I couldn't yet find the sparsebundles with the modified sources and build output directories. As I said I did not have any 10.6 betas with ppc kexttools and kxld, so I had to build the 10.6 kernel against the 10.5.8 environment.

Is that GM version nearly identical to 10.6.0? If so, then the 10.6.1 kernel might also work with the same modifications.
One very desirable thing would be to get TLS 1.2 or even 1.3 with modern cipher suites into the Security framework and/or the kernel - one prerequisite for a Snow Leopard WebKit really being worth the effort (an immense effort that still would be for one single person...).

 

[educovas]

Excellent @educovas! Did you build this using DarwinBuild on Snow Leopard or from the command line?

I couldn't get DarwinBuild to work here. I found a tutorial with the necessary dependencies and compiled it myself. I'm terrible at compiling things lol

I've asked some friends to help me with DarwinBuild because it seems essential to properly boot the GM since I currently need to build kext_tools and DirectoryService to have any progress.

That's really great!
I searched my backups and old hard drives and did find the darwinbuild buildroot directory where I had the sources of xnu from 10.5.8 and 10.6.2 in a 9L30 buildroot. Unfortunately I couldn't yet find the sparsebundles with the modified sources and build output directories. As I said I did not have any 10.6 betas with ppc kexttools and kxld, so I had to build the 10.6 kernel against the 10.5.8 environment.

Is that GM version nearly identical to 10.6.0? If so, then the 10.6.1 kernel might also work with the same modifications.
One very desirable thing would be to get TLS 1.2 or even 1.3 with modern cipher suites into the Security framework and/or the kernel - one prerequisite for a Snow Leopard WebKit really being worth the effort (an immense effort that still would be for one single person...).

The GM is the 10.6.0 release so it might work for newer builds, maybe even 10.6.8 could be a possibility in the future if we ever get the GM to boot properly.

 

[MacPro2006VBox]

I mean…

OT, but that’s interesting… had no idea there was a Moscow, OH.

 

[MacPro2006VBox]

View attachment 2376010

Build 10A432(GM) boots successfully into single user mode after building a custom kernel and restoring the removed ppc binaries.

There was no need to replace anything in the xnu source, just delete and adjust some stuff that's in the attached text file. I still don't know if this kernel works 100% but seems ok so far.

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.

 

[educovas]

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.

I have no idea since I only have one PowerPC machine to test.

 

[ChrisCharman]

I couldn't get DarwinBuild to work here. I found a tutorial with the necessary dependencies and compiled it myself. I'm terrible at compiling things lol

I've asked some friends to help me with DarwinBuild because it seems essential to properly boot the GM since I currently need to build kext_tools and DirectoryService to have any progress.


The GM is the 10.6.0 release so it might work for newer builds, maybe even 10.6.8 could be a possibility in the future if we ever get the GM to boot properly.

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?

 

[ChrisCharman]

I have no idea since I only have one PowerPC machine to test.

I’m sure if you upload the kernel some of us would be able to assist with testing on here.

 

[educovas]

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?

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.

 

[educovas]

I’m sure if you upload the kernel some of us would be able to assist with testing on here.

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.