Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Status
The first post of this thread is a WikiPost and can be edited by anyone with the appropiate permissions. Your edits will be public.

Should continued work on 10.6.8 PowerPC and Xcode 3.2.X have its own dedicated thread?

  • Yes - I would like to be able to follow and/or contribute to a Developer Preview thread specifically

    Votes: 0 0.0%
  • Indifferent - I don't care either way i just appreciate the work that's being done

    Votes: 0 0.0%

  • Total voters
    15
  • Poll closed .
I’ve just finished catching myself up a bit. Skimmed through this entire thread, and a bit of the other one. I have been slowly getting into the retro computing hobby again after awhile.

Seems like I’ve missed quite a lot, because 2 weeks ago I was under the impression SL-PPC was still at 10A190 with no graphics acceleration on AGP GPUs, only PCI and PCIe.

Anyway, I’ve just booted up the image in this thread on my PowerBook5,4 and, I’m glad I decided to come back and read the whole thing, because I was real confused when it had a self-assigned IP address.
I manually configured an IP, and my router/DNS and I am able to ping my local network just fine, but it won’t go to the outside world. It also will not connect to my NAS but it can ping it, as well as every other device on my network. How odd. Regardless this seems to be a huge step forward overall from the DP builds that I had last used.
 
Last edited:
I’ve just finished catching myself up a bit. Skimmed through this entire thread, and a bit of the other one. I have been slowly getting into the retro computing hobby again after awhile.

Seems like I’ve missed quite a lot, because 2 weeks ago I was under the impression SL-PPC was still at 10A190 with no graphics acceleration on AGP GPUs, only PCI and PCIe.

Anyway, I’ve just booted up the image in this thread on my PowerBook5,4 and, I’m glad I decided to come back and read the whole thing, because I was real confused when it had a self-assigned IP address.
I manually configured an IP, and my router/DNS and I am able to ping my local network just fine, but it won’t go to the outside world. It also will not connect to my NAS but it can ping it, as well as every other device on my network. How odd. Regardless this seems to be a huge step forward overall from the DP builds that I had last used.
Welcome back @Project Alice. Networking and Security/Authorisation stacks need more work. I will try building and replacing the relevant AOSP’s soon and report back.
 
  • Like
Reactions: Project Alice
I think it would be a good idea to save the first post only for things related to 10.6.8 (download link, instructions, known problems and workarounds) since it's what most people would look for and move the other stuff like timeline and history to the second and third posts to make it easier to understand and update the first post.
Sounds reasonable. How about the wikipost as a working document, containing all current information and links for the builds (10.6.8 & Xcode Tools), the second post for history and further information, and the third post for resources like references to useful documentation and guides etc?
 
Sounds reasonable. How about the wikipost as a working document, containing all current information and links for the builds (10.6.8 & Xcode Tools), the second post for history and further information, and the third post for resources like references to useful documentation and guides etc?
Sounds good. My idea is to keep the first post with the information needed to test and contribute to 10.6.8/Xcode because it can be easily updated unlike the other posts that can have static information.
 
I think it would be a good idea to save the first post only for things related to 10.6.8 (download link, instructions, known problems and workarounds) since it's what most people would look for and move the other stuff like timeline and history to the second and third posts to make it easier to understand and update the first post.

BTW, we should make an SDK with corresponding changes in system files.
 
things related to 10.6.8

Do we have any utility in those two AHCI kexts that send my PowerMac into KP whenever I forget to disable them on a new installation? ) I may not be the only one affected, at least potentially. If they are incompatible with powerpc anyway, perhaps just disable them in the image?
 
Just to leave my 2 cents on the whole PPC Snow Leo stuff, I think the whole effort makes the most sense in trying to achieve a fully-updated, no-parts-missing, PPC Mac OS X 10.6.8 Snow Leopard (Client AND Server editions), rather than stick with just the Developer Alphas Apple released. Meaning that the main value of the Apple alphas are as stepping stones. In other words, what this forked thread is about.

By the way, I know you guys are still looking into recompiling the Apple "open"-source stuff first, and also in getting MacPorts going for this, but I thought I'd mention, since you guys are even recompiling the 10.6.8 kernel yourselves and possibly tinkering with it, you might want to take a "just-in-case" jab at getting Classic from 10.4.11 Tiger to run. I know, we weren't able to do it (yet) with even 10.5.8 Leopard, but we aren't recompiling the 10.5.8 kernel here, but rather the 10.6.8 one. I also know there might be all other sorts of technical limitations besides the kernel to make it happen, too, but I figured this is worth a mention nonetheless.

I am one of those many silent observers who eagerly keep up with the progress on this effort in the hopes that it reaches a "true" 10.6.8 state someday, so never underestimate just exactly how many people are looking forward to this and appreciating all your efforts and accomplishments.
 
BTW, we should make an SDK with corresponding changes in system files.
Hopefully someone can do that when/if 10.6.8 PPC is usable.

Do we have any utility in those two AHCI kexts that send my PowerMac into KP whenever I forget to disable them on a new installation? ) I may not be the only one affected, at least potentially. If they are incompatible with powerpc anyway, perhaps just disable them in the image?
I don't know which kexts are causing that panic since I don't have it on my machines but maybe you could check if they exist in 10.5.8 and could work on 10.6.8.
 
  • Like
Reactions: ChrisCharman
Just to leave my 2 cents on the whole PPC Snow Leo stuff, I think the whole effort makes the most sense in trying to achieve a fully-updated, no-parts-missing, PPC Mac OS X 10.6.8 Snow Leopard (Client AND Server editions), rather than stick with just the Developer Alphas Apple released. Meaning that the main value of the Apple alphas are as stepping stones. In other words, what this forked thread is about.
Unfortunately, it's impossible to have a "no-parts-missing PPC 10.6.8" without the missing proprietary source code for drivers, apps, and other executables. The best we can do is fix some of the remaining bugs and hope it can get somewhat usable.
By the way, I know you guys are still looking into recompiling the Apple "open"-source stuff first, and also in getting MacPorts going for this, but I thought I'd mention, since you guys are even recompiling the 10.6.8 kernel yourselves and possibly tinkering with it, you might want to take a "just-in-case" jab at getting Classic from 10.4.11 Tiger to run. I know, we weren't able to do it (yet) with even 10.5.8 Leopard, but we aren't recompiling the 10.5.8 kernel here, but rather the 10.6.8 one. I also know there might be all other sorts of technical limitations besides the kernel to make it happen, too, but I figured this is worth a mention nonetheless.
Getting classic to work on 10.5 would be a huge challenge, when I looked at this months ago, I noticed that Apple removed the init functions for classic that should exist in the CoreGraphics framework and it's not something we could recompile because it's not open source.
 
Hopefully someone can do that when/if 10.6.8 PPC is usable.

I bumped into an OpenGL issue with a build, though it seems that on 10.6.8 I would rather get an undefined symbol error than a missing symbol at linking, since this is on 10a190, but with updated frameworks from your earlier patch. I have checked 10.6.8, looks like the related header is not there (which is expected, if the framework has been borrowed from 10.5.8).
I bring this here not due to 10a190 (where I could borrow instead the framework from your build of 10.6.8 rather than an older core graphics patch), but in a context of OpenGL on 10.6.8 as such.

Do you think there is something we could realistically do to bring it closer to what 10.6.8 release has?

If sources do not exist publicly, maybe later builds still have ppc slices and are functional? You may have already checked everything, of course, I am just not aware of exact status of the issue.
If there is something I can do in this regard, I am interested.

Everything Xorg, SDL and Wayland rely on OpenGL in the system, and on PowerPC this stuff is of crucial importance, since nothing of modern Cocoa can be supported, which means that native GUI backend is not an option for anything modern. However, via Xorg, SDL and possibly, later on, Wayland, modern software can work.

P. S. On a side note, maybe you could enable your GH, if it is not too much of a hassle? If you prefer not to be public there, it does not need to be associated with your identity elsewhere. I could just tag you in relevant issues, so that you could read those when interested. Rather than bringing all technical stuff here, which may not always be of interest for others.
 
Unfortunately, it's impossible to have a "no-parts-missing PPC 10.6.8" without the missing proprietary source code for drivers, apps, and other executables. The best we can do is fix some of the remaining bugs and hope it can get somewhat usable.

Getting classic to work on 10.5 would be a huge challenge, when I looked at this months ago, I noticed that Apple removed the init functions for classic that should exist in the CoreGraphics framework and it's not something we could recompile because it's not open source.

Could the CoreGraphics framework from 10.4.11 be used in 10.5.8 (and 10.6.8)? And how feasible would it be to hex edit those init functions back into the 10.5.8+ framework, copying them from 10.4.11? Or, if that's too difficult, then how feasible would it be to decompile the various binaries with IDA Pro and the like, then add the init functions in, then recompile? (Note: decompiled function and variable names might be able to be made clearer by giving them to some AI large language model to get it to spit out more meaningful names. Should help.)

I did not know the drivers and so many other non-GUI parts were closed source. Goes to show how much of a PR stunt the whole "open source" stance is when coming from companies, institutions and certain individuals. I guess reverse-engineering, hex editing and/or writing things from scratch are the only options.

I also like @barracuda156's idea on looking out for PPC slices in existing commercial 10.6.8 binaries, too.

No matter the route, this is all quite involved, but IMO worth the effort. It's pretty cool.
 
I bumped into an OpenGL issue with a build, though it seems that on 10.6.8 I would rather get an undefined symbol error than a missing symbol at linking, since this is on 10a190, but with updated frameworks from your earlier patch. I have checked 10.6.8, looks like the related header is not there (which is expected, if the framework has been borrowed from 10.5.8).
I bring this here not due to 10a190 (where I could borrow instead the framework from your build of 10.6.8 rather than an older core graphics patch), but in a context of OpenGL on 10.6.8 as such.

Do you think there is something we could realistically do to bring it closer to what 10.6.8 release has?

If sources do not exist publicly, maybe later builds still have ppc slices and are functional? You may have already checked everything, of course, I am just not aware of exact status of the issue.
If there is something I can do in this regard, I am interested.

Everything Xorg, SDL and Wayland rely on OpenGL in the system, and on PowerPC this stuff is of crucial importance, since nothing of modern Cocoa can be supported, which means that native GUI backend is not an option for anything modern. However, via Xorg, SDL and possibly, later on, Wayland, modern software can work.

P. S. On a side note, maybe you could enable your GH, if it is not too much of a hassle? If you prefer not to be public there, it does not need to be associated with your identity elsewhere. I could just tag you in relevant issues, so that you could read those when interested. Rather than bringing all technical stuff here, which may not always be of interest for others.
Yes, that is problem. IOSurface doesn't exist on 10.5 so the options here are: remove the need for IOSurface from that app somehow or whatever it's doing that's calling that OpenGL function or try to use a newer GL/CoreGraphics from around 10A190/10A222 but that would work only for the PCI Nvidia GPUs so I never bothered to try that. One thing I tried was to use the drivers from 10A190 with OpenGL from 10A432 (GM) but it's already not compatible.

For what I could see, build 10A222 removed the PPC slices for the Nvidia drivers so I don't think we have any newer drivers available for ppc. It should be theoretically possible to add shims to the driver or OpenGL to have compatibility but it's definitely out of my skills.

What I could do is a different image with the OpenGL from 10A190 for IOSurface support but I don't know how useful that would be since it's limited to a small amount of machines. Or maybe keep stock 10.6.8 OpenGL/CoreGraphics but with no graphics acceleration.
 
Could the CoreGraphics framework from 10.4.11 be used in 10.5.8 (and 10.6.8)? And how feasible would it be to hex edit those init functions back into the 10.5.8+ framework, copying them from 10.4.11? Or, if that's too difficult, then how feasible would it be to decompile the various binaries with IDA Pro and the like, then add the init functions in, then recompile? (Note: decompiled function and variable names might be able to be made clearer by giving them to some AI large language model to get it to spit out more meaningful names. Should help.)

I did not know the drivers and so many other non-GUI parts were closed source. Goes to show how much of a PR stunt the whole "open source" stance is when coming from companies, institutions and certain individuals. I guess reverse-engineering, hex editing and/or writing things from scratch are the only options.

I also like @barracuda156's idea on looking out for PPC slices in existing commercial 10.6.8 binaries, too.

No matter the route, this is all quite involved, but IMO worth the effort. It's pretty cool.
Using the CoreGraphics from Tiger wouldn't be a good idea, Tiger and Leopard are considerably different, in the case of getting it to boot with it, many things would be very broken. Reverse engineering and adding those functions the new CoreGraphics is theoretically possible but haven't looked much into that because it's not something I'd be able to do.
 
  • Like
Reactions: ChrisCharman
What I could do is a different image with the OpenGL from 10A190 for IOSurface support but I don't know how useful that would be since it's limited to a small amount of machines. Or maybe keep stock 10.6.8 OpenGL/CoreGraphics but with no graphics acceleration.

If it is possible, it will be awesome in fact. Both for usability with Nvidia cards and for testing purposes.
 
  • Like
Reactions: ChrisCharman
@educovas keeping graphics acceleration is a must so i would say stick with the current configuration until we have more fixes for the 10A190 or 10.6.8 versions. The 10A190 version doesn’t provide full acceleration unfortunately, though it partially works on some systems. Although the current setup provides obstacles for us in terms of development, for the users wanting to test run 10.6.8 on PowerPC, graphical acceleration is a big selling point versus the developer previews and the systems being targeted all have support under 10.5.

Perhaps someone not busy with rebuilding core system components…perhaps someone from the old hackintosh community?…may wish to have a look at writing new drivers or backwards engineering some of the proprietary bits.

@barracuda156 we should definitely create a PowerPC sdk for the build, i did suggest we do the same when we were working on the other builds, but when its complete i feel it would be more appropriate as otherwise we’ll have to keep updating the sdk as well.
 
  • Like
Reactions: Jubadub
Using the CoreGraphics from Tiger wouldn't be a good idea, Tiger and Leopard are considerably different, in the case of getting it to boot with it, many things would be very broken. Reverse engineering and adding those functions the new CoreGraphics is theoretically possible but haven't looked much into that because it's not something I'd be able to do.
I think this would be a welcome addition down the line, for someone looking to take that on, as it would create the ultimate best of both worlds system for Mac PowerPC. If a thread pops up exploring this idea, i will certainly be following along.
 
  • Like
Reactions: Jubadub
Just to keep all in the loop, i’ve settled into my new home after moving recently and will be able to start building again soon. I have a temporary setup at the moment until i get a new desk etc, and a few of the machines have some issues that need sorting but we’re getting there.

8538E19B-851E-47B2-A9C9-F2D5265DFCDF.jpeg
 
@educovas keeping graphics acceleration is a must so i would say stick with the current configuration until we have more fixes for the 10A190 or 10.6.8 versions. The 10A190 version doesn’t provide full acceleration unfortunately, though it partially works on some systems. Although the current setup provides obstacles for us in terms of development, for the users wanting to test run 10.6.8 on PowerPC, graphical acceleration is a big selling point versus the developer previews and the systems being targeted all have support under 10.5.

Perhaps someone not busy with rebuilding core system components…perhaps someone from the old hackintosh community?…may wish to have a look at writing new drivers or backwards engineering some of the proprietary bits.

@barracuda156 we should definitely create a PowerPC sdk for the build, i did suggest we do the same when we were working on the other builds, but when its complete i feel it would be more appropriate as otherwise we’ll have to keep updating the sdk as well.
I'll make an alternative image with OpenGL from 10A190 only for the compatible Nvidia GPUs. I'll keep what we have currently for the other machines since it provides the best experience even if some apps need some work to be compatible with 10.6.8 ppc.
 
I'm quietly watching in the background, super excited, absolutely blown away by this bombshell of an announcement. I put my head down in 2020 when 10A190 was released and reviewed.. and yesterday I was jumping up and down with joy when 10.6.8 booted up on my 1.25 15" PowerBook G4!! It's been having KP's although I believe it's due to the dying KingSpec SSD in there. Am happy to test things out, encourage progress, and am writing up an article on low end Mac! Seriously, bravo, keep up the good work!! Love this love this love this.
 

Attachments

  • Screenshot 2024-11-28 at 4.58.55 PM.png
    Screenshot 2024-11-28 at 4.58.55 PM.png
    2.2 MB · Views: 39
I'm quietly watching in the background, super excited, absolutely blown away by this bombshell of an announcement. I put my head down in 2020 when 10A190 was released and reviewed.. and yesterday I was jumping up and down with joy when 10.6.8 booted up on my 1.25 15" PowerBook G4!! It's been having KP's although I believe it's due to the dying KingSpec SSD in there. Am happy to test things out, encourage progress, and am writing up an article on low end Mac! Seriously, bravo, keep up the good work!! Love this love this love this.
Your KPs could be related to sleep. At least for me the OS is considerably more stable if I disable sleep.
 
I'll make an alternative image with OpenGL from 10A190 only for the compatible Nvidia GPUs. I'll keep what we have currently for the other machines since it provides the best experience even if some apps need some work to be compatible with 10.6.8 ppc.

Thank you very much.

By the way, can we control version which modified or replaced frameworks report to whatever links to them? For example, I swapped back original 10a190 frameworks (on 10a190), and got two ports broken:
Code:
Incompatible library version: /opt/local/bin/toxic requires version 64.0.0 or later, but /System/Library/Frameworks/QuartzCore.framework/Versions/A/QuartzCore provides version 1.2.0
Incompatible library version: /opt/local/libexec/vlc2/lib/vlc/plugins/video_output/libcaopengllayer_plugin.dylib requires version 64.0.0 or later, but /System/Library/Frameworks/QuartzCore.framework/Versions/A/QuartzCore provides version 1.2.0

The problem is not these ports, of course, it is a matter of rebuilding them, but compatibility of software between 10a190 and 10.6.8 (when 10.5 frameworks are borrowed) in principle. While in some specific cases compatibility genuinely cannot be had (say, when something uses IOSurface), arguably in most such breakage is unnecessary and is caused simply by versions mismatch.

If these can be changed, it is probably sensible to bring versions of 10.5 frameworks to whatever 10a190 has (so that all usable versions of 10.6 have same versions here).

Any thoughts on this?
 
Incidentally, do we yet have a list of software that will run on PowerPC 10.6.8, but not in 10.5.8? Or in 10.6.8, but not even in 10A190/10A96?

I have seen once or twice some 10.6.x software compiled as Universal Binaries, so they'd be perfect for checking this, except I forgot their names.
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.