Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Snow Leopard on Unsupported PowerPC Macs
- Thread starter Larsvonhier
- WikiPost WikiPost
- Start date
- Sort by reaction score
- Status
Yes, I am.
No, I can’t. My PowerBook (what I call my “$25 mule”), when I bought it, came with a replacement logic board (i.e., no embedded serial number), but for reasons beyond my technical ability to pinpoint, the system immediately kernel-panics in the very earliest stages of booting when the A1126 combo AirPort/BT (on the A1138s) is connected to the logic board. I’ve tried swapping A1126s with the one from my A1139, and I even bought a second flat cable to connect A1126 to the board. None of this resolved the issue, so all of my SL-PPC work (or when I boot into 10.5.8) has been done without the means to use AirPort or Bluetooth.
Worse, I’ve even tried to use my 802.11n PC card which I use with my A1139 (it uses the Broadcom framework in OS X, thus letting the system “see” the card as device-native and controllable via the usual AirPort menubard pulldown), and the same issue which kernel-panics my A1138 board with AirPort/BT kernel-panics when anything is detected on the PC card bus.
$25 bought me a lot, but I also got what I paid for.
It would.
Unfortunately, I can’t really provide that right now with how I have things set up (and my A1139 is tasked with, of all things, my email client, soon to be orphaned by Google, yay).
When I have the mental bandwidth and time to re-focus on that effort, I will, and I’ll let you know how it goes. I kind of have to be in the mood to throw myself into that, and I sort of lost that mood sometime around last September (for reasons you might be able to extrapolate from our past conversations).
I followed the same instructions on both the iBook G4 and PowerBook G4 and was able to get functional wifi under 10A190. Perhaps try again and check permissions on all files copied over from 10A096. Failing that, it’s possible that the particular model of airport card you’re using is not compatible.
DarwinBuild is broken for PowerPC, under Leopard and Snow Leopard. I was only able to get it working under Mountain Lion and the resulting 10432 kernel build was i386/X86_64 completely removing PPC compatibility, which is present in the retail kernel. I believe this was a configuration issue however as DarwinBuild was most likely linking to the system (Mountain Lion) which is intel only. Perhaps you would have more luck seeing as you’ve managed to cross compile successfully under 10.6.8 for PPC. It’s not something i’ve had time to look at again recently.
Yeah that is a claim that was advertised. It is false. Sorbet has absolutely no code from Snow Leopard, nor is it related in anyway to Snow Leopard. It is marketing only. Sorbet IS Leopard 10.5.8 but with some tweaks and additional, already available and previously released, themes and wallpapers. It is simply another way to package the ‘authors’ previously released Leopard tweaks and scripts but as a preinstalled image, for those not savvy enough to tweak Leopard themselves. The confusion caused by riding on the PowerPC Snow Leopard hype is something that has been discussed over on that thread, which is where all Sorbet discussions belong.
Broken. Tried on 10.5.8 as well as 10A190. Legacy is only for up to Darwin 8. I think the best route would be to install on intel Snow Leopard and modify the source to include PowerPC, but that is a project someone would need to dedicate a fair amount of time into.
DarwinBuild for SnowLeopard is designed to exclude PowerPC. It will require source code modification to change that. There is a build error under Leopard but i forget which port is missing or changed that has broken 10.5 compatibility.
I’m still keen on this idea. I don’t have time to get the ball rolling currently but will contribute for sure.
1. For wifi, I will give it another go today. I see no point in having Leopard on G4 due to no ppc64, and Tiger it too ancient. I am also perhaps not motivated enough to fix stuff for Tiger.
2. Thank you for clarifying, I wanted to make sure if darwinbuild is broken just for me or inherently. Xcode project of it lists ppc archs as valid, only darwinbuild itself is set to build as Intel (which can be changed manually). But yeah, I guess some frameworks or w/e may be just missing on PPC. I will give it a try, when I have mood. I suspect I tried on 10.6.8 before and it failed.
So when you build system components from AOS, you do it without a specific environment? I wanna work on this part, but dunno really where to start.
This was surprisingly easy: all I had to do is edit away +universal requirement in portfile and edit arch in prefix.xcconfig (plain text file).
Code:
macmini:~ svacchanda$ sw_vers
ProductName: Mac OS X Server
ProductVersion: 10.6.8
BuildVersion: 10K549
macmini:~ svacchanda$ port -v installed darwinbuild
The following ports are currently installed:
darwinbuild @37_0 (active) requested_variants='' platform='darwin 10' archs='ppc' date='2022-03-16T11:43:05+0800'It has also built against 10A190 SDK and after editing plists on Leopard and Snow Leopard to include ppc64 and ppc, respectively. Let’s see if it will be functional.
P. S. Natively it fails to build on this:
Code:
Checking Dependencies...
** BUILD FAILED **
The following build commands failed:
darwinup:
CompileC /opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_devel_darwinbuild/darwinbuild/work/darwinbuild-37/build/darwinbuild.build/Public/darwinup.build/Objects-normal/ppc/Database.o /opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_devel_darwinbuild/darwinbuild/work/macosforge-darwinbuild-fc5cb47/darwinup/Database.cpp normal ppc c++ com.apple.compilers.gcc.4_2
(1 failure)
Last edited:
I build them from the command line. I would suggest starting with updating the tools needed to build but i imagine the tools you’ve built using MacPorts will be sufficient, although you may need to install some of the tools and headers that are only used for internal projects - the build error logs will light the way. Out of interest, have you attempted to replace any of the system binaries with the ones you’ve built in MacPorts? I haven’t done this as i like to make sure that i build things the ‘Apple’ way to ensure they’re built as intended, but I noticed that some of the ports you’ve successfully built are also on the AOSP list. If you do this, it would probably be wise to try and stick to the version numbers that shipped with 10.6.
I tried changing the arch to PowerPC when I attempted this on Mountain Lion and it still built only for intel. Hopefully by using the 10A190 SDK under 10.6.8 you will have more luck. Could you try building the 10A432 kernel in DarwinBuild to see if it does indeed build for PowerPC?
No, I haven’t replaced OS components so far. If we talk about Unix tools there may not be much sense in that either (I could be wrong though).
The major things that do not build and maybe never would are LLVM (newer than 8), Clang, Qt5, Java 8+ and modern browsers. Otherwise we got at this point fully functional Macports environment.
Rust might be fixed (once they implement gcc support in mrustc), go might be fixed, ghc probably can be fixed (on the latter I plan to work).
On Mountain Lion you won’t be able to run ppc binaries and am not sure you can force Macports to build for ppc even if you follow XcodeLegacy procedure to restore ppc assembler. I didn’t try but 10.6.8 seems to be a more logical and certainly less painful pathway.
gcc can be built as a cross-compiler for ppc though.
P. S. I will update a bit later on darwinbuild. I wanted to install it into 10A190 but forgot to bring the drive along.
If your goal is to update the system from beta to something that resembles 10432 then that includes the BSD level binaries that the system is built upon, but by all means don’t feel that you have to replace the unix level components if you don’t want to. If you’re happy with your current set-up then by all means continue to use as-is.
I’ve been following your MacPorts efforts and it seems that you’ve achieved a great deal, which is great to see. Having said that, the goal of this project is to get the operating system fixed and updated so i will continue to focus on that for the foreseeable future because, other than for us tinkerers, there isn’t going to be a user base for new software on Snow Leopard for PowerPC while it remains buggy and less current than Leopard.
I will attempt to follow your GCC11 guide when i find a spare few days to play around with this stuff again.
Yes i’m aware that Mountain Lion has no support for PowerPC, but it was the only system i was able to get DarwinBuild functional enough to build the 10A432 kernel on at the time. Let me know how you get on with 10.6.8 and 10A190 efforts.
The problem is that gcc10 and gcc11 fail to build on 10A190 outside of Macports, at least so far they failed for me, and I believe, no one else even tried. So in the context of this thread important point is not Macports per se but rather ability to finally build the modern compiler natively.
You have seen that I already had gcc11 on 10A190 for some time, however that was pre-built on 10.6.8. While this is a feasible route, it is arguably more problematic to follow (you will need to have 10.6.8 to begin with) and potentially less safe (it is definitely preferable to use a natively built compiler).
By now there is a reproducible way to get gcc11 on 10A190 without an aid of another OS and with minimal efforts. Once done, it can be used for whatever needs, and not necessarily inside Macports.
P. S. For rebuilding 10.6 components, from what I understand there are two quite distinct groups: components of OS itself (which of course we do want to get updated to 10A432 or 10.6.8 level) and Unix tools to build software (which are optional components that Xcode installs). The latter are not a part of OS itself. Also some components like curl are outdated even in 10.6.8 and are practically unusable anyway.
I do hope to be able to replace cctools though.
The Xcode tools source code can be identified by following the link - brings you to the same list however the Xcode specific projects are highlighted with a bullet point.
Replacing CCTools is a must if you plan on building system components, though i would err on the side of caution when it comes to updating system binaries beyond what was shipped with 10A432 initially as changes between versions will no doubt cause unexpected issues down the line. Once we have parity with 10A432, or a close as we can get, then we can look at further updates in my opinion.
Has anyone been able to fix Blutooth on 10A190 by the way?
Airport fails for me. Replaced airportd, all kext, frameworks etc with ones from 10A96 – airport can be turned on, it sees networks, but fails to connect.
Airport fails for me. Replaced airportd, all kext, frameworks etc with ones from 10A96 – airport can be turned on, it sees networks, but fails to connect.
Have you been trying to drop on the 10A96 components into 10A190, or have you been trying to drop in the 10.5.8 components into 10A190?
Although I haven‘t been able to test BT/AirPort hardware directly on my test Mac, I have been able to verify that the following components brought over from 10.5.8 do load correctly on 10A96. The following are those elements brought over from 10.5.8 which have loaded and/or launch in 10A96 (emphasis here on the Frameworks):
Thank you. I was using 10A96 components (with no luck). Will try those from 10.5.8.
I don’t yet want to complicate this too much, but…
I’m having a closer look at the solution presented in #513 and seeing how the 10A190 fix relies on components from 10A96, even as I was moving components from 10.5.8 into 10A96 in my testing (emphasis for a reason). The components brought over to 10A190 from 10A96 in #513 aren’t entirely homologous to what’s in 10.5.8.
For instance, there’s an AirPort.framework in 10A96 (and 10A190); there isn’t one in 10.5.8. How this change impacts functionality is likely vital, but something I don’t yet know.
Additionally, there’s an AirPort-related component from 10.5.8 whose version number is lower than in 10A96/10A190 (and also why it’s no longer listed in Table 4): IO80211Family.kext. In 10.5.8, it’s version 2.1.6; in 10A96, it’s version 3.0.0. I don’t know what version is in 10A190.
Keep these in mind when making your moves from 10A96 and/or 10.5.8. I’m curious to learn what you discover.
I installed it on my iMac G5 20" and acceleration was not working unfortunately. I was optimistic that it would work but no.
This was tested on a PowerMac12,1 and not a PowerMac8,2 — correct?
EDIT to add:
Also, if so, were you able to test this after bringing over the following kexts from 10.5.8 (copied from Table 4)?
Last edited:
I replaced a large chunk of components from the Table in Wikipost and that just killed the OS. It hangs at boot now. Having a dejavu, I vaguely recall I already got that result once on my Quad.
Permissions shouldn’t be the issue, I used sudo, will check later if I forgot to pull something that I deleted. But likely some components are either inherently incompatible or mutually incoherent.
Dunno how to test these, it’s crazy to move those one-by-one rebooting every time LOL
Maybe just try exactly what post #513 presented?
That’s literally what I did for 10A96 testing… which is why Table 4 is kind of valuable: that’s quite a few
Maybe just try exactly what post #513 presented?
That’s literally what I did for 10A96 testing… which is why Table 4 is kind of valuable: that’s quite a fewhoursdaysweeks of testing.
@barracuda156 unfortunately this is the testing process we must endure. The same is also true for the testing of compiled system components. Probably also why we have very few people contributing as testers.
By the way if you have info at hand, please let me know which components you were able to replace and that did not ruin the OS. At least we can save each others’ efforts since we concentrate primarily on different aspects.
Update on broken components in 10A222. These has to be sourced from 10A190:
Code:
/usr/bin/bsdmake
/usr/bin/gm4
/usr/bin/gnumake
/usr/bin/ld
/usr/bin/malloc_history
/usr/bin/m4
/Developer/usr/bin/bsdmake
/Developer/usr/bin/gm4
/Developer/usr/bin/gnumake
/Developer/usr/bin/ld
/Developer/usr/bin/malloc_history
/Developer/usr/bin/m4Apropos of nothing, my PowerBook test mule for 10A96 had a system freeze (not strictly a kernel panic) earlier today, showing a blank screen but with keyboard backlight on. I held the power button to reboot, as always. The reboot was fine and uneventful.
Why am I posting this? Think of it as a diary entry. I had Interface Builder up on the main screen for months, where I meant to come back around and work on something (UI elements related to Finder), but I hadn’t found the time or the motivation. Around the time of the Club 15 post I made, I remember running an “uptime” command” and it reporting I’d had the system up for about 67 days. That post was made on 8 February.
Since I can’t know exactly for sure how long uptime was before the freeze, I can extrapolate. That would have been 41 days ago — meaning, an estimated (low-end guess) for how long the system was up since last reboot: 108 days.
My assessment: not bad for an early alpha release of an OS which was ultimately scuttled for this architecture.
Why am I posting this? Think of it as a diary entry. I had Interface Builder up on the main screen for months, where I meant to come back around and work on something (UI elements related to Finder), but I hadn’t found the time or the motivation. Around the time of the Club 15 post I made, I remember running an “uptime” command” and it reporting I’d had the system up for about 67 days. That post was made on 8 February.
Since I can’t know exactly for sure how long uptime was before the freeze, I can extrapolate. That would have been 41 days ago — meaning, an estimated (low-end guess) for how long the system was up since last reboot: 108 days.
My assessment: not bad for an early alpha release of an OS which was ultimately scuttled for this architecture.
If anyone interested, I have apparently fixed Perl6 (Rakudo) for PPC and built llvm-7.1 and libtapi.
Last edited:
On 10.6.8 Darwinbuild starts its routines, however it pulls from somewhere its initial plist arch settings and tries to use those, which obviously fails. It may not be completely hopeless though, at least it is not totally broken.
I installed pre-built Darwinbuild into 10A190, and there it seems broken. Chances are there I messed up settings, I will give it another go in a while.