When you happen to have few minutes, please give a brief instruction on rebuilding OS components from AOS. I am ready to deal with this, since I need at least blocks runtime and libdispatch fixed, and neither works in 10.6 PPC.
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
When you happen to have few minutes, please give a brief instruction on rebuilding OS components from AOS. I am ready to deal with this, since I need at least blocks runtime and libdispatch fixed, and neither works in 10.6 PPC.
I installed 10A190 in Parallels, and yes, it can run both Intel and PPC binaries. Rosetta shows up from 10A222.
It won’t run Intel-only apps on PPC, which is what I guess the post you replied to asked about.
Indeed, only PowerVM_Lx86 can do that on ppc linux, and Rosetta is based on it but in the other direction. As sources aren't available, the only path to running intel binaries on ppc would be something like:
Intel app -> Darling -> PowerVM_Lx86 -> Noah ppc -> OSX ppc 🤣🤣🤣
It should not be that hard. Apple sources are available (from 10.6 and new), plus we have at least two implementations of libdispatch on GitHub.
Sure enough, none of these gonna build with zero effort, but given a number of platforms supported, should be quite doable.
Unfortunately darwinbuild is broken, otherwise building for ppc would likely amount to adding an extra arch.
P. S. Re support burden for developers: I think you overstate the problem. Very few ports require 10.6 PPC-specific fixes. Out of those, some can be built with setting deployment target to 10.5 or using a newer Perl/Python.
GCC still requires dedicated and non-upstreamable fix, that’s pretty much it. Even this may be upstreamed if we find a way to identify developer builds as distinct from 10.6.0 case. Apple headers have needed defines like DEVELOPMENT_STAGE, but I am not yet sure how to use them.
Just built TFF from the latest commit on 10A190:
Actually though, have any of you tried rebuilding Leopard Webkit? It obviously builds on 10.5 PPC, and Tobias said the code could be built for 10.6 Intel relatively easily, so it seems like 10.6 PPC ought to be doable as well.
You won't get the latest version of Webkit, obviously, but it would be a heck of a lot more up-to-date than what comes with Snow Leopard!
(I don't own any PPC Macs, I'm just watching from afar!)
Found to be hopeless endeavor: https://trac.macports.org/ticket/64994#comment:2
Here is some complicated trickery: https://www.insanelymac.com/forum/topic/17767-borisbadenov-ati-x1000-series-solution/
I was thinking - can we try directly building the https://github.com/freedesktop/xorg-xf86-video-ati linux driver for mac (as a kernel module) and then use https://docs.mesa3d.org/macos.html
I have been trying almost exactly that using an intel mac framebuffer fork, I do get it to compile and detect HD4XXX cards however I get no display out of those as of yet. Initialisation stalls as the rom likely need to be read from file (a bit as for firmware-linux-nonfree) as the FB module looks for the ROM at intel-specific legacy addresses, or one needs to determine whether it can be read directly and where.
Radeon HD cards on PowerPC Leopard using osx86-driver-radeonhd framebuffer driver?
Hi everyone, Since reading up on some open source framebuffer drivers / injectors for hackintoshes (e.g. Callisto, ATY_init), I've been wondering about the possibility of porting those to PowerPC. While I haven't been able to find the source code for Callisto or ATY_init (@netkas might have the...
forums.macrumors.com
Last edited:
I will check with dong luo if he's okay with a fork of his work being on github (where he originally put it), I haven't yet got around to reading in the rom from file as I was stuck with a very trivial dependency issue with the headers required by fopen in Xcode, will take a look again
Regarding rebuilding opensource OS components:
I just thought that we do not need to invent a bicycle with custom build environment or bother fixing a broken darwinbuild.
Instead, use Macports with overlay repo (which is needed on 10A190 anyway). What will be needed specifically:
1. Write portfiles with needed versions of components naming them to be distinct, like gnumake-snow.
2. Set /usr as the prefix with configure.pre_args. See also an example of replacement variant of libcxx port.
3. Make sure system compilers are used: compiler.whitelist gcc-4.2. Probably also use OS cctools (see example of gcc10-bootstrap).
4. Use OS headers and libs: compiler.cpath /usr/include, compiler.library_path /usr/lib. Or something to this end.
5. A bit tricky part: either use move in post-destroot to rename OS component in question (so that install conflict does not happen) or install the port into Macports’s /var/system_roots, from where it can be moved into OS manually. The second option is safer and arguably preferable. If direct install into OS is chosen, add destroot.violate_mtree yes.
More or less, this is a trivial task. I can make a couple of portfiles to test, if anyone interested. (These won’t be committed to Macports master, of course, it is for our own use. I can add these to my SL-PPC tree on GitHub though.)
Disclaimer: I have no idea if this can be done for xnu, since there is no existing port for it. But likely yes, just may be a bit more demanding.
I just thought that we do not need to invent a bicycle with custom build environment or bother fixing a broken darwinbuild.
Instead, use Macports with overlay repo (which is needed on 10A190 anyway). What will be needed specifically:
1. Write portfiles with needed versions of components naming them to be distinct, like gnumake-snow.
2. Set /usr as the prefix with configure.pre_args. See also an example of replacement variant of libcxx port.
3. Make sure system compilers are used: compiler.whitelist gcc-4.2. Probably also use OS cctools (see example of gcc10-bootstrap).
4. Use OS headers and libs: compiler.cpath /usr/include, compiler.library_path /usr/lib. Or something to this end.
5. A bit tricky part: either use move in post-destroot to rename OS component in question (so that install conflict does not happen) or install the port into Macports’s /var/system_roots, from where it can be moved into OS manually. The second option is safer and arguably preferable. If direct install into OS is chosen, add destroot.violate_mtree yes.
More or less, this is a trivial task. I can make a couple of portfiles to test, if anyone interested. (These won’t be committed to Macports master, of course, it is for our own use. I can add these to my SL-PPC tree on GitHub though.)
Disclaimer: I have no idea if this can be done for xnu, since there is no existing port for it. But likely yes, just may be a bit more demanding.
This isn't about the windowing system per se. Webkit-GTK (so called even if installed from Macports with +quartz) is an OS X port of the Linux port of Webkit.
Leopard-webkit is a backport of the original Apple version of webkit. (It's not in MacPorts).
They're just very different beasts.
Thanks for clarifying.
Apple Webkit is opensource, why don’t we make a Portfile for it and build in Macports? (If it works, we can submit it to Macports master.)
I think just because "no one has done it", by all means give it a shot. https://sourceforge.net/p/leopard-webkit/wiki/BuildInstructions/
(I think https://sourceforge.net/p/leopard-webkit/wiki/BuildInstructionsSecurity/ isn't needed on Snow Leopard, which is good because it looks quite involved.)
Mind, you're still going to end up with a 2017-era version of Safari since that's where internetzel stopped maintaining it, but that's still well ahead of what you'd have otherwise.
Without an updated Security framework you'll practically not be able to establish any type of secure https connection. And I don't know whether the updated framework today would be able to establish significantly more connections.
Do you know which version of it we need to be properly functional?
Provided we have source code on AOS, we can build it in Macports prefix and link to there, so that OS one does not have to be replaced (since replacing may cause compatibility issues).
Impossible to get any later version of it than the one from Leopard-WebKit, because the cryptographic part of the framework was moved to the kernel in later OS versions.
In order to not have to replace the system version of the Security framework you'd have to relink it like the relinking app which comes with Leopard-WebKit does.
Another option would be to avoid touching the Security framework and using an HTTPS mitm proxy instead.
Unless someone can get Squid working reliably on PPC, this would require the use of a secondary machine, but I know @wicknix uses a setup like this with Leopard Webkit.
Alternately, fixing Squid on PPC would probably be easier than recompiling the Security framework (much less updating it).
Last edited: