Snow Leopard on Unsupported PowerPC Macs

[barracuda156]

View attachment 2372550

So, after a lot of work I got build 10A222 booting on PPC.

Hundreds of binaries lost ppc support and had to be downgraded to 10A190 and older Like Preference Panes, most of /Applications, /bin, Kexts and some apps in CoreServices like Finder. Also had to write a kext to stub a couple kernel symbols required by the old IONDRVSupport kext and compile /usr/sbin/notifyd from AOSP.

I haven’t tested much this build and patches so I don’t know how stable it is.

I’ve imaged a patched install including some updated files and apps, QE/CI, WiFi and Bluetooth patches. This image should hopefully work with all PowerPC Macs that were supported by 10.5.8.

File on MEGA

mega.nz

Does not boot on Quad, unfortunately. Just fans go mad and loading screen.

Initially it went into KP, but that was due to two faulty kexts (same on 10a190). Removed those, no KP, but no booting

I can try on a PowerBook though.

UPD. On PB G4 it boots fine. It would be cool to have G5 working, I cannot do any development work on G4, that is unbearably slow LOL

 

[barracuda156]

/bin, Kexts and some apps in CoreServices like Finder. Also had to write a kext to stub a couple kernel symbols required by the old IONDRVSupport kext and compile /usr/sbin/notifyd from AOSP.

In principle, we should consider rebuilding xnu and libSystem.B from sources, preferably those of 10.6.8.

The problem with 10a190 and alike, leaving trivial user experience issues like wifi or buggy finder side, is that libraries and headers are not what the software expects. So some stuff will be missing completely, some partially present, some present, but under different names. (I gave a few examples earlier here.)
This creates a non-trivial problem with making a good use of a newer system – sure enough, with simple hacks we can use 10.5 codepaths, but this diminishes the advantage of having 10.6.

Since darwinbuild appears broken (though it might work to build universal from i386, I did not go into that direction so far), what can be used is Macports environment with sterilized environment (i.e. nothing from Macports prefix should be used or linked to, only build-time tools being used).
A relevant example is a port for libdispatch (which builds on 10a190, and apparently produces a functional libdispatch for ppc – I was able to link against it, dropping 10.5 fallbacks): https://github.com/macports/macport...61db349e99c/devel/libdispatch-legacy/Portfile

Unfortunately, we do not have ready recipes for libc and friends, AFAIU. So those have to be re-created (libdispatch is a component of libSystem, but I build it standalone, the same provisionally should work for other components, even if the whole thing cannot be built – say, some crucial component does not have source code available).
Apple did some nasty stuff to make our life harder LOL
Some functions are missing or broken on ppc from libpthreads, for example, which in turn breaks a lot of stuff (pthread_threadid_np is made available only for x86, as an example, which breaks build of Python 3.12). These issues can only be fixed by building from source, since pthread_threadid_np, using this example, is missing even in 10.6.8 Rosetta (ppc slice is there, but some symbols are hidden, etc.).

 

[ChrisCharman]

In principle, we should consider rebuilding xnu and libSystem.B from sources, preferably those of 10.6.8.

The problem with 10a190 and alike, leaving trivial user experience issues like wifi or buggy finder side, is that libraries and headers are not what the software expects. So some stuff will be missing completely, some partially present, some present, but under different names. (I gave a few examples earlier here.)
This creates a non-trivial problem with making a good use of a newer system – sure enough, with simple hacks we can use 10.5 codepaths, but this diminishes the advantage of having 10.6.

Since darwinbuild appears broken (though it might work to build universal from i386, I did not go into that direction so far), what can be used is Macports environment with sterilized environment (i.e. nothing from Macports prefix should be used or linked to, only build-time tools being used).
A relevant example is a port for libdispatch (which builds on 10a190, and apparently produces a functional libdispatch for ppc – I was able to link against it, dropping 10.5 fallbacks): https://github.com/macports/macport...61db349e99c/devel/libdispatch-legacy/Portfile

Unfortunately, we do not have ready recipes for libc and friends, AFAIU. So those have to be re-created (libdispatch is a component of libSystem, but I build it standalone, the same provisionally should work for other components, even if the whole thing cannot be built – say, some crucial component does not have source code available).
Apple did some nasty stuff to make our life harder LOL
Some functions are missing or broken on ppc from libpthreads, for example, which in turn breaks a lot of stuff (pthread_threadid_np is made available only for x86, as an example, which breaks build of Python 3.12). These issues can only be fixed by building from source, since pthread_threadid_np, using this example, is missing even in 10.6.8 Rosetta (ppc slice is there, but some symbols are hidden, etc.).

Same situation we’ve been in since the beginning. Unfortunately, nobody has been able to rebuild the kernel for the PowerPC architecture, some compatibility remains but there needs to be some new code written and in order to do that someone needs to invest a lot of time learning the languages needed and writing, testing and implementing the new code. If you believe your experience with macports will help i implore you to give it a bash mate. Maybe with use of the ‘stubber’ tool it may even be possible to get the retail 10A432 kernel to boot, but with limited functionality. Otherwise we’ll just have to continue to optimise and update the builds as far as we can with the knowledge accrued from the people testing and tinkering, and the free time available to those willing to contribute, and see where we end up.

 

[barracuda156]

Same situation we’ve been in since the beginning. Unfortunately, nobody has been able to rebuild the kernel for the PowerPC architecture, some compatibility remains but there needs to be some new code written and in order to do that someone needs to invest a lot of time learning the languages needed and writing, testing and implementing the new code. If you believe your experience with macports will help i implore you to give it a bash mate. Maybe with use of the ‘stubber’ tool it may even be possible to get the retail 10A432 kernel to boot, but with limited functionality. Otherwise we’ll just have to continue to optimise and update the builds as far as we can with the knowledge accrued from the people testing and tinkering, and the free time available to those willing to contribute, and see where we end up.

Have you tried rebuilding libSystem or its parts? (I am not sure how much of it relies on kernel, but this arguably will have a bigger impact if done.)

P. S. Wonder if Darwinbuild folks had any success back then; it seems that their build system assumes that everything necessary was available, though I have no idea whether it ever actually worked.

 

[barracuda156]

Not yet This is a nut we’re still trying to crack.

There was no update ever since, or did I miss it? Leopard sees the PCIe SSD, but if I could make it run from there, that would be great.

 

[educovas]

Just in case, did anyone fix Network Sharing from 10.6? System Preferences crashes when I try to enable internet sharing there.

Unfortunately i can't test that so I don't know if it works or not with these new patches.

Does not boot on Quad, unfortunately. Just fans go mad and loading screen.

Initially it went into KP, but that was due to two faulty kexts (same on 10a190). Removed those, no KP, but no booting

I can try on a PowerBook though.

UPD. On PB G4 it boots fine. It would be cool to have G5 working, I cannot do any development work on G4, that is unbearably slow LOL

Unfortunately there is nothing I can go, I don't have access to a G5 machine but it might be due to no ppc64 support for most binaries, they are mostly for ppc7400 and I have no idea if a G5 can use ppc7400 binaries or if the problem is on the kernel side like missing kexts.

In principle, we should consider rebuilding xnu and libSystem.B from sources, preferably those of 10.6.8.

The problem with 10a190 and alike, leaving trivial user experience issues like wifi or buggy finder side, is that libraries and headers are not what the software expects. So some stuff will be missing completely, some partially present, some present, but under different names. (I gave a few examples earlier here.)
This creates a non-trivial problem with making a good use of a newer system – sure enough, with simple hacks we can use 10.5 codepaths, but this diminishes the advantage of having 10.6.

Since darwinbuild appears broken (though it might work to build universal from i386, I did not go into that direction so far), what can be used is Macports environment with sterilized environment (i.e. nothing from Macports prefix should be used or linked to, only build-time tools being used).
A relevant example is a port for libdispatch (which builds on 10a190, and apparently produces a functional libdispatch for ppc – I was able to link against it, dropping 10.5 fallbacks): https://github.com/macports/macport...61db349e99c/devel/libdispatch-legacy/Portfile

Unfortunately, we do not have ready recipes for libc and friends, AFAIU. So those have to be re-created (libdispatch is a component of libSystem, but I build it standalone, the same provisionally should work for other components, even if the whole thing cannot be built – say, some crucial component does not have source code available).
Apple did some nasty stuff to make our life harder LOL
Some functions are missing or broken on ppc from libpthreads, for example, which in turn breaks a lot of stuff (pthread_threadid_np is made available only for x86, as an example, which breaks build of Python 3.12). These issues can only be fixed by building from source, since pthread_threadid_np, using this example, is missing even in 10.6.8 Rosetta (ppc slice is there, but some symbols are hidden, etc.).

So, even 10.6.8 have a big portion of the OS compiled for PowerPC, including xnu, most libs in /usr/lib including libSystem.B, Frameworks and PrivateFrameworks and more, I'm almost sure that's for Rosetta support.

xnu does not want to boot on PowerPC (It's already compiled for PPC) so I don't think that just rebuilding would help much, someone would have to fix this problem which I definitely can't do.

I've been trying to boot newer builds but with mostly no success. The best I got was 10A286 booting to single user mode with the 10.0.0d3 kernel.

WiFi and Finder would always be from 10A190 or older since there is no PowerPC support (I think Apple removed PPC support for anything that's not needed for Rosetta), WiFi stack does not support the old kext and more.

Same situation we’ve been in since the beginning. Unfortunately, nobody has been able to rebuild the kernel for the PowerPC architecture, some compatibility remains but there needs to be some new code written and in order to do that someone needs to invest a lot of time learning the languages needed and writing, testing and implementing the new code. If you believe your experience with macports will help i implore you to give it a bash mate. Maybe with use of the ‘stubber’ tool it may even be possible to get the retail 10A432 kernel to boot, but with limited functionality. Otherwise we’ll just have to continue to optimise and update the builds as far as we can with the knowledge accrued from the people testing and tinkering, and the free time available to those willing to contribute, and see where we end up.

Since the kernel is still compiled for the ppc architecture, I'm guessing they removed the "unnecessary" code for booting on PowerPC machines. It should be possible to figure out what's wrong and resolve the problem bug even with that, we'd still have to use a lot from 10A190 and older since there are basically no executable with ppc support.

Have you tried rebuilding libSystem or its parts? (I am not sure how much of it relies on kernel, but this arguably will have a bigger impact if done.)

P. S. Wonder if Darwinbuild folks had any success back then; it seems that their build system assumes that everything necessary was available, though I have no idea whether it ever actually worked.

Rebuilding libSystem and other libs shouldn't be needed since they do seem to work fine on PowerPC (at least the one from 10A286 but since even the one from 10.6.8 was compiled For PPC, it should also work).

In theory, it should be possible to mix 10.6.8 with 10A190, with the core of the OS from 10.6.8 and executables and other binaries without ppc code from 10A190 but that's definitely not easy and not something I can do without a lot of help, unfortunately.

 

[barracuda156]

Unfortunately i can't test that so I don't know if it works or not with these new patches.


Unfortunately there is nothing I can go, I don't have access to a G5 machine but it might be due to no ppc64 support for most binaries, they are mostly for ppc7400 and I have no idea if a G5 can use ppc7400 binaries or if the problem is on the kernel side like missing kexts.


So, even 10.6.8 have a big portion of the OS compiled for PowerPC, including xnu, most libs in /usr/lib including libSystem.B, Frameworks and PrivateFrameworks and more, I'm almost sure that's for Rosetta support.

xnu does not want to boot on PowerPC (It's already compiled for PPC) so I don't think that just rebuilding would help much, someone would have to fix this problem which I definitely can't do.

I've been trying to boot newer builds but with mostly no success. The best I got was 10A286 booting to single user mode with the 10.0.0d3 kernel.

WiFi and Finder would always be from 10A190 or older since there is no PowerPC support (I think Apple removed PPC support for anything that's not needed for Rosetta), WiFi stack does not support the old kext and more.


Since the kernel is still compiled for the ppc architecture, I'm guessing they removed the "unnecessary" code for booting on PowerPC machines. It should be possible to figure out what's wrong and resolve the problem bug even with that, we'd still have to use a lot from 10A190 and older since there are basically no executable with ppc support.


Rebuilding libSystem and other libs shouldn't be needed since they do seem to work fine on PowerPC (at least the one from 10A286 but since even the one from 10.6.8 was compiled For PPC, it should also work).

In theory, it should be possible to mix 10.6.8 with 10A190, with the core of the OS from 10.6.8 and executables and other binaries without ppc code from 10A190 but that's definitely not easy and not something I can do without a lot of help, unfortunately.

A quick reply on two points:

1. 10a190 boots and works perfectly fine on G5. G5 CPUs fully support 32-bit ppc code. (In fact reverse may be broken: for example, FreeBSD ppc64 images are supposed to work on G5, but since FreeBSD 13 they do not.)
So no, it cannot be possibly related to a lack of ppc64 support, which was never supported in the kernel and completely absent from 10a190 (which works though).

Perhaps I could try debugging it in a silly way, restoring suspicious components one-at-a-time, and eventually it should work.

2. As long as choice is there (and assuming away costs in terms of extra time spent), rebuilding from source is always a better solution than swapping components.
With swapped components we never know it is a coherent setup; if something later on breaks, it may be hard to pin down where exactly the error originates from.
(I also do not really know how swapping headers will work, in principle. If headers are left untouched, but libraries swapped, this perhaps only shows up when something is built against those. And verily likely builds gonna fail. If headers are also swapped, that can introduce unexpected consequences elsewhere, since headers are shared by different components.)

If you just stick libSystem from 10.6.8 into 10a190, that won’t work. Assuming it boots at all, you will have headers inconsistent with symbols in the library (libdispatch is one example, where things will break badly, but not the only one).

 

[barracuda156]

UPD. Tried now on 2.3 Dual, which does not have exotic PCIe cards, and same story: fans running high, Apple logo with rolling boot wheel. No success either.

 

[educovas]

1. 10a190 boots and works perfectly fine on G5. G5 CPUs fully support 32-bit ppc code.

As you can see, I know nothing about G5s lol

If you just stick libSystem from 10.6.8 into 10a190, that won’t work. Assuming it boots at all, you will have headers inconsistent with symbols in the library (libdispatch is one example, where things will break badly, but not the only one).

Yes, it won't work with just libSystem, but it should be possible if you swap some other binaries. Like I almost got 10A222 to boot properly with all libs in /usr/lib, and some frameworks from 10A286 but I was getting some problems with DirectoryService, in this case building from source would help since it's frameworks are compiled For PPC but the daemon is Intel only.

UPD. Tried now on 2.3 Dual, which does not have exotic PCIe cards, and same story: fans running high, Apple logo with rolling boot wheel. No success either.

Did you try to boot in verbose? Maybe you can see where it's failing...

 

[barracuda156]

As you can see, I know nothing about G5s lol


Yes, it won't work with just libSystem, but it should be possible if you swap some other binaries. Like I almost got 10A222 to boot properly with all libs in /usr/lib, and some frameworks from 10A286 but I was getting some problems with DirectoryServices, in this case building from source would help since it's frameworks are compiled For PPC but the daemon is Intel only.

Rebuilding daemon should be pretty trivial, perhaps, if we have source code.

I will try verbose. Of course now I want to build next snapshot of gcc13 against a new SDK ))

 

[barracuda156]

Did you try to boot in verbose? Maybe you can see where it's failing...

It gets stuck on this with fans:

 

[educovas]

It gets stuck on this with fans:

Hmmm, that's pretty difficult to figure out what's happening... I think launchd started and is trying to launch stuff and something important is failing (that's mostly what I've been fighting trying to boot newer 10.6 builds). The reason why it's failing in my case is usually a problem with fat binaries, permissions or intel only daemons/libs.

 

[barracuda156]

Hmmm, that's pretty difficult to figure out what's happening... I think launchd started and is trying to launch stuff and something important is failing (that's mostly what I've been fighting trying to boot newer 10.6 builds). The reason why it's failing in my case is usually a problem with fat binaries, permissions or intel only daemons/libs.

Since the same image which cannot boot on G5 boots fine on G4, perhaps it is not something as generic as wrong permissions. (After I removed two kexts causing KP on G5, I successfully booted the same thing on a PowerBook.)

I don’t really know how to debug the OS itself. Do we have a comprehensive list of what was swapped from other OS versions?

 

[ChrisCharman]

Libsystem in Mac OS is not really a library @barracuda156 it is a wrapper for multiple libraries, and it is linked to the kernel.

Building everything from source is preferable, but we don’t have the sources for anything proprietary so it’s difficult to rebuild everything from scratch without some seriously time consuming backwards engineering - AOSP are useful in some instances, as are the open code sources for many third party projects that were utilised in 10.6 however, many components of the OS require to be built against private headers or private frameworks, and we don’t have access to those. Further, Apple intentionally crippled a lot of source code to function on a Darwin ‘based’ OS but not in OS X, out of box.

Regarding the G5 compatibility, my assumption would be that the kernel lacks power management or other hardware drivers specific to the G5. You could try using the kernel debug kit version of the kernel to see more verbose output. I would try this but my G5 is currently buried behind a mountain of my daughters things.

 

[ChrisCharman]

Since the same image which cannot boot on G5 boots fine on G4, perhaps it is not something as generic as wrong permissions. (After I removed two kexts causing KP on G5, I successfully booted the same thing on a PowerBook.)

I don’t really know how to debug the OS itself. Do we have a comprehensive list of what was swapped from other OS versions?

We have a zipped file uploaded to Mega of the components swapped into 10A222

 

[barracuda156]

Libsystem in Mac OS is not really a library @barracuda156 it is a wrapper for multiple libraries, and it is linked to the kernel.

Building everything from source is preferable, but we don’t have the sources for anything proprietary so it’s difficult to rebuild everything from scratch

1. Yes, I know, but it is easier to use an umbrella term than to list all included libs
By the way, it looks like components can be “updated” without messing up with existing libSystem: at least with libdispatch it works (as long as flags pointing to the new headers and lib come before sysroot, build uses the right library and ignores whatever OS has originally).

From point of view of third-party software we have a problem with libpthreads and libdispatch. Everything else, more or less, is either trivial or hopeless.

2. Do I understand correctly, that we do not know what we don’t have of what’s needed?
I am not particularly interested in something like rebuilding Finder from source – there are third-party apps which work better anyway.
Rebuilding xnu and libSystem (or at least its core components) would be a big deal. It may not actually be as hard as simply time-consuming. Analyzing source + darwinbuild recipes + what libs are actually linked to in the OS should give the list of dependencies. Then from makefiles you could reconstruct how to implement a working build. But it is a lot of boring work.

P. S. libdispatch uses some private headers. Passing -DPRIVATE does the magic LOL

 

[ChrisCharman]

1. Yes, I know, but it is easier to use an umbrella term than to list all included libs
By the way, it looks like components can be “updated” without messing up with existing libSystem: at least with libdispatch it works (as long as flags pointing to the new headers and lib come before sysroot, build uses the right library and ignores whatever OS has originally).

From point of view of third-party software we have a problem with libpthreads and libdispatch. Everything else, more or less, is either trivial or hopeless.

2. Do I understand correctly, that we do not know what we don’t have of what’s needed?
I am not particularly interested in something like rebuilding Finder from source – there are third-party apps which work better anyway.
Rebuilding xnu and libSystem (or at least its core components) would be a big deal. It may not actually be as hard as simply time-consuming. Analyzing source + darwinbuild recipes + what libs are actually linked to in the OS should give the list of dependencies. Then from makefiles you could reconstruct how to implement a working build. But it is a lot of boring work.

P. S. libdispatch uses some private headers. Passing -DPRIVATE does the magic LOL

1. Yeah, symlinks or building static libraries within apps can also work but it’s not ideal and not recommended in the Apple documentation because the system depends on the specific version of Libsystem that it was built against. I mean, obviously Apple don’t recommend building or modifying any system components but i’m just stating it. The issue with most system level components comes down to circular dependencies and incomplete source code. Building Libsystem is very complex even for supported architectures.

2. I have only used DarwinBuild on Lion to successfully build a Snow Leopard kernel and because it was on Lion it wasn’t universal. If you can get the Leopard/Snow Leopard compatible tarball from the macports tree working again, then in theory we could probably make some use of that, you just set it to build from a local repo and modify the source code where needed. Building the kernel isn’t the issue though, it’s rewriting and updating it to replace the intel optimisations that make Snow Leopard different to Leopard. It’s more than just byte swapping, there are functions that are not relevant which can be disregarded but some that are fundamental but make use of specific architecture features that aren’t present on PPC, though some may have analogues, the code would still need to be rewritten. If we simply get it to boot and return 0 for anything unsupported then really we’re no better off than we would be in Leopard, potentially worse off as PPC optimisations would have been stripped. You can use the -file and -otool tools to find out what the dependencies are of a binary if you wanna look into it, that’s what I did. Figuring out the order in which to build everything given the circular dependencies however just gave me a headache.

3. Libdispatch would be very useful if we could integrate it as a replacement for the system version, assuming it performs the same functions. Apple made SOME private headers available, mainly for iOS developers and for Swift but not all of the ones that we need unfortunately.

My advice would be to read the literature on OS X Leopard and OS X Snow Leopard (like OS X for UNIX geeks) and as much official developer documentation as you can find. There’s no clear path to achieve what we’d like, which is why this is an ongoing learning process and there’s no list of everything needed to modify or rebuild OS X, in whole or in part.

@educovas getting 10A222 to boot using parts from previous seeds and Leopard is the largest step forward we’ve had for a long time. I imagine before the next we’ll have a long period of tinkering and thread derailing in the interim as most people do not have the time, incentive, resources or knowledge to contribute. I will tinker some more soon and share anything I find.

 

[barracuda156]

Re 10a222: let’s try to get in running on G5. Without that pretty much nothing will be done both for toolchain (modern gcc, updated cctools) and user apps.
It is not just a matter of preference, it is a hard constraint on performance. It took a couple of days to get Rawtherapee from “architecture unsupported” to a working app with gui only because I could run multiple rebuilds on G5.
It could be that more end-users have PowerBooks, but no G5 support in effect means no testing and no fix-ups beyond very basic stuff.

 

[internetzel]

Strictly, the G5 does not fully support 32 bit PowerPC code (e.g. ppc7400) - a few instructions or variations of them are missing and the xnu kernel used to emulate those, IIRC. (After all the G5 is a POWER4 cpu and not a PowerPC one.)

I remember that many years ago I rebuilt a 10.6.? kernel for my PowerBook G4 and managed to have it boot to single user - for that purpose I had replaced the kext loading mechanism with the one from 10.5 .
And that 10.6 kernel did not boot on a G5 - it halted with some error message like "unsupported platform".
I do not remember any more details, but rebuilding the kernel was not that hard back then.

 

[educovas]

The 10A222 kernel (10.0.0d3) does support G5 since it did load and loaded kexts. I'm almost sure kernel is not the problem since it already started launchd but I can't help much without having a G5 machine.

 

[ChrisCharman]

@barracuda156 if you replace the 10A222 kernel with the debug kernel and symbols, we may be able to figure out where the hang is occurring. I shared it previously on here and it’s on the garden alongside the other builds previously uploaded. I can’t test this myself as my G5 is currently inaccessible, i will test 10A222 in the coming weeks on several G4’s however and see if there’s any merit in using it as the new base system for my previous efforts.

I feel like you have macports running pretty well on 10A190 now so there may not be any benefits to starting again on 10A222 for you, particularly if G5 compatibility remains an issue.

Can anyone verify that the version of Libsystem in 10A222 is the same as 10A190 please? I remember stating this previously but it was an anomaly seeing as all other versions have a new version of Libsystem along with a new Kernel - it did seem to make sense at the time given the relative ease moving components between these two builds but it could have also been an error on my part when recording my findings. Confirming this or disaffirming this would be useful. If the version of Libsystem is indeed the same and @educovas has moved many components over from 10A190, then it stands to reason that your existing Macports and compiled binaries should work without changes needing to be made.

Further, one reason you might want to use 10A222, should we manage to get it running on G5s is that this seed laid the foundation for the libdispatch api - which if you’re seriously considering replacing may offer better results than 10A190.

 

[ChrisCharman]

Strictly, the G5 does not fully support 32 bit PowerPC code (e.g. ppc7400) - a few instructions or variations of them are missing and the xnu kernel used to emulate those, IIRC. (After all the G5 is a POWER4 cpu and not a PowerPC one.)

I remember that many years ago I rebuilt a 10.6.? kernel for my PowerBook G4 and managed to have it boot to single user - for that purpose I had replaced the kext loading mechanism with the one from 10.5 .
And that 10.6 kernel did not boot on a G5 - it halted with some error message like "unsupported platform".
I do not remember any more details, but rebuilding the kernel was not that hard back then.

Am I correct when i say that the G5 will run G4 binaries but without altivec instructions? I believe I read that in the Apple documentation somewhere some time ago.

 

[educovas]

@barracuda156 if you replace the 10A222 kernel with the debug kernel and symbols, we may be able to figure out where the hang is occurring. I shared it previously on here and it’s on the garden alongside the other builds previously uploaded. I can’t test this myself as my G5 is currently inaccessible, i will test 10A222 in the coming weeks on several G4’s however and see if there’s any merit in using it as the new base system for my previous efforts.

I feel like you have macports running pretty well on 10A190 now so there may not be any benefits to starting again on 10A222 for you, particularly if G5 compatibility remains an issue.

Can anyone verify that the version of Libsystem in 10A222 is the same as 10A190 please? I remember stating this previously but it was an anomaly seeing as all other versions have a new version of Libsystem along with a new Kernel - it did seem to make sense at the time given the relative ease moving components between these two builds but it could have also been an error on my part when recording my findings. Confirming this or disaffirming this would be useful. If the version of Libsystem is indeed the same and @educovas has moved many components over from 10A190, then it stands to reason that your existing Macports and compiled binaries should work without changes needing to be made.

Further, one reason you might want to use 10A222, should we manage to get it running on G5s is that this seed laid the foundation for the libdispatch api - which if you’re seriously considering replacing may offer better results than 10A190.

I don't think libSystem is the same since it seems to be constantly updated on every new build but from my limited experience, a new libSystem is usually compatible with apps made for earlier builds and I do think that macports might work fine.

I'm sure that 10A190 is still a better option for everything since 10A222 is still pretty "new".

 

[ChrisCharman]

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)

This is the earlier post that i would like to be verified @educovas

 

[ChrisCharman]

I’ve tried several times now to restore @educovas modified 10A222 disk image to one of my PowerBooks to no avail. Disk utility throws an error and corrupts the drive, and trying to restore using CCC succeeds but isn’t bootable. What method was used to create the .dmg and has it been tested? May be an issue with the .dmg and not a G4 vs G5 problem after all