Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
I've been very pleased with the availability of packages even on the ppc64 Leopard install (on my 2.3 DC PMG5), really the only hangup thus far has been gcc stuff - currently in the midst of building right now lol. But thankfully a much smaller problem that it would be to build it on any G4. I am having issues when trying to install gemini-cli, as one of the dependencies can't seem to be found anywhere (darwin-xtools-0.7.0_1). Any idea what the story might be on that? It works fine on my 10.6.8a install.
 
I can do a test with DingusPPC. It's needed for the boot chime. Without an audio unit, the emulated Mac never sees the audio end.

The thing is that while translating between portable and non-portable dispatch syntax is straightforward (so it is pretty easy to change clang-only source to compatible with gcc), translating from dispatch to no-dispatch is not. It might be a better idea to see if 10.6 version works first. If it does and 10.5 is really needed, then try with that.

I've been very pleased with the availability of packages even on the ppc64 Leopard install (on my 2.3 DC PMG5), really the only hangup thus far has been gcc stuff - currently in the midst of building right now lol. But thankfully a much smaller problem that it would be to build it on any G4. I am having issues when trying to install gemini-cli, as one of the dependencies can't seem to be found anywhere (darwin-xtools-0.7.0_1). Any idea what the story might be on that? It works fine on my 10.6.8a install.

gcc is available pre-built, of course, as well as darwin-xtools. You are likely trying to use variants that mismatch defaults. Check what the website has in packages_ppc64/gcc14 (and whatever other port), you can see which versions, which variants and which archs are available. If you prohibited universal or set different archs than ppc+ppc64, that will prevent some ports from using pre-built variants on 10.5.
 
The thing is that while translating between portable and non-portable dispatch syntax is straightforward (so it is pretty easy to change clang-only source to compatible with gcc), translating from dispatch to no-dispatch is not. It might be a better idea to see if 10.6 version works first. If it does and 10.5 is really needed, then try with that.
cubeb can use jack or pulseaudio instead of audiounit. I was unable to port install jack.

With cubeb using pulseaudio as the backend on Mac OS X 10.5.8, dingusppc can get beyond the boot chime but I didn't actually hear any sound. I need to fix endian issues with some of the emulated hardware (byte swap macros are used in some places instead of the little-endian or big-endian macros).
 
I recall someone was using Emacs? While the build is broken both on 10.5.8 and 10.6.8, it magically works on my 10a190, so I will add updated pre-built packages of it to PPCPorts (ports compiled on 10a190 can run on 10.6.8). Update will be needed now once libxml2 is updated (which I plan to do soon, together with ICU).
 
  • Like
Reactions: milliectl
@Matias_ @Forest Expertise @doctor_dog I am planning to push updates of libxml2 and icu tonight, unless something goes badly wrong with an important dependent. This will trigger a lot of rebuilds of heavy stuff, and likely cause occasional breakages. However I do not want to leave this pending indefinitely, and being off-sync with MacPorts does not make life easier. (It is trivial to stay on current versions without updating and without rebuilds locally, of course, if that is desired.)

Update. Folks, ready for rebuilding 5 versions of boost, every mysql, mariadb and postgresql, katie and kde/katana-libs, gdal and god knows how many gnome ports?
 
Last edited:
gcc is available pre-built, of course, as well as darwin-xtools. You are likely trying to use variants that mismatch defaults. Check what the website has in packages_ppc64/gcc14 (and whatever other port), you can see which versions, which variants and which archs are available. If you prohibited universal or set different archs than ppc+ppc64, that will prevent some ports from using pre-built variants on 10.5.
Thanks for this! I realized a few issues with my setup. Turns out my conf files needed a bit of editing as you figured. Good heads up for those also using on 10.5.8
 
  • Like
Reactions: barracuda156
@Matias_ @Forest Expertise @doctor_dog I am planning to push updates of libxml2 and icu tonight, unless something goes badly wrong with an important dependent. This will trigger a lot of rebuilds of heavy stuff, and likely cause occasional breakages. However I do not want to leave this pending indefinitely, and being off-sync with MacPorts does not make life easier. (It is trivial to stay on current versions without updating and without rebuilds locally, of course, if that is desired.)

Update. Folks, ready for rebuilding 5 versions of boost, every mysql, mariadb and postgresql, katie and kde/katana-libs, gdal and god knows how many gnome ports?

Updates are in, I will try to complete most of rebuilds for 10.6 today.
 
After syncing yesterday my PB g4 compiled stuff for Hours. All went well. Except Handbrake. Threw an error while configuring.

UPD.: After cleaning handbreit, installing all other Updates I got. handbrake working again.
 
Last edited:
  • Like
Reactions: barracuda156
@Matias_ @Forest Expertise @doctor_dog I am planning to push updates of libxml2 and icu tonight, unless something goes badly wrong with an important dependent. This will trigger a lot of rebuilds of heavy stuff, and likely cause occasional breakages. However I do not want to leave this pending indefinitely, and being off-sync with MacPorts does not make life easier. (It is trivial to stay on current versions without updating and without rebuilds locally, of course, if that is desired.)

Update. Folks, ready for rebuilding 5 versions of boost, every mysql, mariadb and postgresql, katie and kde/katana-libs, gdal and god knows how many gnome ports?

Phew that was quite intense. But I believe I finished all the rebuilds. Some minor breakages (mostly archaic stuff) but nothing too bad, pretty much everything still works!
 
  • Like
Reactions: barracuda156
Phew that was quite intense. But I believe I finished all the rebuilds. Some minor breakages (mostly archaic stuff) but nothing too bad, pretty much everything still works!

It will be useful to know what fails. (Note, there was a time between MacPorts update of libxml2 and our update, so if you built some dependent of libxml2 which is used from MacPorts during that time, it has to be force upgraded now, since revbump was mistimed; examples: py*-lxml ports, libcroco etc.)
 
Given the bump in interest for 10.4 Tiger (in big part because of the strides made on PowerFox and its port, MachFox) I've been doing more tinkering with it myself. Usually my Tiger machines live a happy life doing basic media, web, etc. But I'm curious if anyone here has gotten PPCPorts running well on 10.4? Thinking of giving it a try on my 12" PBG4, but I have the vague sense that I'd be in for some headaches, haha. Barracuda, you mention in your posts and the website that any support for Tiger is community-based. Any sense of what that community is up to?
 
Given the bump in interest for 10.4 Tiger (in big part because of the strides made on PowerFox and its port, MachFox) I've been doing more tinkering with it myself. Usually my Tiger machines live a happy life doing basic media, web, etc. But I'm curious if anyone here has gotten PPCPorts running well on 10.4? Thinking of giving it a try on my 12" PBG4, but I have the vague sense that I'd be in for some headaches, haha. Barracuda, you mention in your posts and the website that any support for Tiger is community-based. Any sense of what that community is up to?
There is a task that was created for it but it seems like there's not a lot of activity on it since last month: https://github.com/macos-powerpc/powerpc-ports/issues/25

It'd be great if anyone could make PPCPorts work better under Tiger.
 
Given the bump in interest for 10.4 Tiger (in big part because of the strides made on PowerFox and its port, MachFox) I've been doing more tinkering with it myself. Usually my Tiger machines live a happy life doing basic media, web, etc. But I'm curious if anyone here has gotten PPCPorts running well on 10.4?

@Forest Expertise and @glebm may be able to respond on this.

Thinking of giving it a try on my 12" PBG4, but I have the vague sense that I'd be in for some headaches, haha. Barracuda, you mention in your posts and the website that any support for Tiger is community-based. Any sense of what that community is up to?

I don’t know LOL

I think the only workable option is to have a separate tree or repo for Tiger stuff and add it as an extra overlay on top of PPCPorts for users of 10.4. While I don’t mind minimal fixes for 10.4 being added to existing ports, that does not result in a working set up for end-users – and cannot result in it in principle, since Tiger needs fixes for ports which work fine on 10.5+ (and thus they are not present in PPCPorts to begin with).
This already can be done by anyone interested without my involvement: adding an extra overlay does not require any hacking or rebuilding the base, it literally amounts to one line added into a plain-text config file.

I had the same problem with MacPorts, which was one of the reasons to bother with independent ports for powerpc: adding fixes to some ports while not being able to add fixes to some other (because somebody is not interested to merge a PR with a fix) forces to keep carrying local overlay with custom hacks, otherwise nothing can work. And for 10.4 now, even though I do not object having fixes merged, there is a different problem with identical outcome: some ports that need fixes are missing. Presently that is left to end-users, which is why we get these questions – unsurprisingly, nothing works on 10.4 as-is.
 
There is a task that was created for it but it seems like there's not a lot of activity on it since last month: https://github.com/macos-powerpc/powerpc-ports/issues/25

I marked it as “task” because it was not a bug report but rather, well, a task. It did not imply it is my task. Please do not wait for me to do anything in that regard. I do not have particular interest in 10.4, but even if I had, there is no time for it: neither my time nor spare cpu cycles on my powermac. Building for 10.5 is already “unofficially outsourced”.
Things may improve if we have a team of more or less active contributors (like MacPorts does, just on a lesser scale). Most of the time goes for updates, not for fixing something. There are some 4k ports in PPCPorts plus 4k more in R. Just keeping everything reasonably up-to-date is already problematic. And then, sure enough, on every next update something breaks LOL
 
@Forest Expertise and @glebm may be able to respond on this.



I don’t know LOL

I think the only workable option is to have a separate tree or repo for Tiger stuff and add it as an extra overlay on top of PPCPorts for users of 10.4. While I don’t mind minimal fixes for 10.4 being added to existing ports, that does not result in a working set up for end-users – and cannot result in it in principle, since Tiger needs fixes for ports which work fine on 10.5+ (and thus they are not present in PPCPorts to begin with).
This already can be done by anyone interested without my involvement: adding an extra overlay does not require any hacking or rebuilding the base, it literally amounts to one line added into a plain-text config file.

I had the same problem with MacPorts, which was one of the reasons to bother with independent ports for powerpc: adding fixes to some ports while not being able to add fixes to some other (because somebody is not interested to merge a PR with a fix) forces to keep carrying local overlay with custom hacks, otherwise nothing can work. And for 10.4 now, even though I do not object having fixes merged, there is a different problem with identical outcome: some ports that need fixes are missing. Presently that is left to end-users, which is why we get these questions – unsurprisingly, nothing works on 10.4 as-is.
In my humble opinion, making fixing stuff a little easier might be a path forward? OS X Server 10.4 is a Universal image, and thus both PPC and Intel pull from the same components and Intel’s codebase is apparently much nicer than the PPC slice. OGL 2 for example exists in a much better state on Server than on PPC Client.

Could attract attention by supporting Tiger Server instead. Problem with that is getting ppl to migrate to Server (and G3 isn’t supported in 10.4.7+). You could also pick up Intel support too this way.
 
In my humble opinion, making fixing stuff a little easier might be a path forward? OS X Server 10.4 is a Universal image, and thus both PPC and Intel pull from the same components and Intel’s codebase is apparently much nicer than the PPC slice. OGL 2 for example exists in a much better state on Server than on PPC Client.

Could attract attention by supporting Tiger Server instead. Problem with that is getting ppl to migrate to Server (and G3 isn’t supported in 10.4.7+). You could also pick up Intel support too this way.

Nothing prevents a user to install any desired version of 10.4; from a point of view of the base, it is just 10.4. If your idea is to do universal builds, that does not make life easier, IMO. But I never even tried that on Tiger either.
P. S. I would be surprised if x86 code in 10.4 is of a higher quality; AFAIK, up to 10.5 powerpc was still prioritized, or at least on par with x86.
 
In my humble opinion, making fixing stuff a little easier might be a path forward? OS X Server 10.4 is a Universal image, and thus both PPC and Intel pull from the same components and Intel’s codebase is apparently much nicer than the PPC slice. OGL 2 for example exists in a much better state on Server than on PPC Client.
Could attract attention by supporting Tiger Server instead. Problem with that is getting ppl to migrate to Server (and G3 isn’t supported in 10.4.7+). You could also pick up Intel support too this way.
I haven't really explored using any of the OS X Server versions, any benefits over the stock versions? I didn't realize G3s had a break between the Server and Consumer versions of Tiger they support, but considering this forum got Leopard to install on G3s (which really boggles me as a concept, because I can only imagine the "fun" of trying to run Leopard on a G3 lol) I can't imagine it's out of the realm of possibility to get the up-to-date 10.4 Server running on them as well. Might even prove a good task if there is a tangible benefit re: my first question. Tack on the Shuriken optimizations and it could be a nice deal.
 
Given the bump in interest for 10.4 Tiger (in big part because of the strides made on PowerFox and its port, MachFox) I've been doing more tinkering with it myself. Usually my Tiger machines live a happy life doing basic media, web, etc. But I'm curious if anyone here has gotten PPCPorts running well on 10.4? Thinking of giving it a try on my 12" PBG4, but I have the vague sense that I'd be in for some headaches, haha. Barracuda, you mention in your posts and the website that any support for Tiger is community-based. Any sense of what that community is up to?
Community fixes for Tiger have mostly just been me (as you can see from the commit history), and I have been derailed onto working on a G4 fork of Machfox. My binary repo isn't even up at the moment because that machine is having to do all my UXP builds, and can't easily spare RAM and CPU cycles for a server at the same time.
You will be in for some headaches, but it is still worth it, imo. You will learn a lot along the way as well. Macports Trac is your friend, most of the stuff that works on Leopard can work on Tiger with routine fixes (you may just want to alias gmake for make, for example).
In my humble opinion, making fixing stuff a little easier might be a path forward? OS X Server 10.4 is a Universal image, and thus both PPC and Intel pull from the same components and Intel’s codebase is apparently much nicer than the PPC slice. OGL 2 for example exists in a much better state on Server than on PPC Client.

Could attract attention by supporting Tiger Server instead. Problem with that is getting ppl to migrate to Server (and G3 isn’t supported in 10.4.7+). You could also pick up Intel support too this way.
Because this is community supported, there is no reason to target Tiger Server unless people in the community are going to test on it and fix for it. I might at some point, but currently I am on Client. Also, trying to support Intel would make things more difficult, not less, because then one has to worry about both big and little endian, among other things. There is no reason to limit to only Tiger Server unless most potential contributors are already using it, otherwise you raise the barrier for community members to make pull requests to fix issues (and reduce potential users). The best way to get it fixed is to have more people working on it, and as I said, I currently can't if I ever want to get a JIT working on G4.

Nothing prevents a user to install any desired version of 10.4; from a point of view of the base, it is just 10.4. If your idea is to do universal builds, that does not make life easier, IMO. But I never even tried that on Tiger either.
P. S. I would be surprised if x86 code in 10.4 is of a higher quality; AFAIK, up to 10.5 powerpc was still prioritized, or at least on par with x86.
They gave Intel 10.4.11 OpenGL 2 support and a slightly newer kernel version: https://web.archive.org/web/2009122...ng/opengl/capabilities/GLInfo_10411Intel.html
PowerPC client never got that.
I assume Tiger has a software renderer for OpenGL2 in 10.4.11 server, even for PPC, though I could be wrong. I'd be really curious if someone with a G5 and a Radeon x1900 could get OpenGL 2 hardware acceleration on Tiger Server

I haven't really explored using any of the OS X Server versions, any benefits over the stock versions? I didn't realize G3s had a break between the Server and Consumer versions of Tiger they support, but considering this forum got Leopard to install on G3s (which really boggles me as a concept, because I can only imagine the "fun" of trying to run Leopard on a G3 lol) I can't imagine it's out of the realm of possibility to get the up-to-date 10.4 Server running on them as well. Might even prove a good task if there is a tangible benefit re: my first question. Tack on the Shuriken optimizations and it could be a nice deal.
There's a newer kernel version, drivers for a PCMCIA card that provides 802.11n wifi for PowerBook G4s, possibly newer OpenGL than Tiger Client.
It does still support G3 according to Macintosh Garden if you don't use the 10.4.7 installer, I don't know if you can upgrade to 10.4.11 or if jktwice is correct that it can't do 10.4.7 or higher at all: https://macintoshgarden.org/apps/mac-os-server-104
 
I assume Tiger has a software renderer for OpenGL2 in 10.4.11 server, even for PPC, though I could be wrong. I'd be really curious if someone with a G5 and a Radeon x1900 could get OpenGL 2 hardware acceleration on Tiger Server
It does in fact have OGL2 HW acceleration and it has 802.11n support. So using, say, PowerFox on a G5 in Tiger is gonna be a lot more usable (but not that much more so. I use PF Intel and while it's awesome you still need to adjust your expectations).

@Jazzzny was curious about this initially and did spin up a quick 10.4.11 Server install and confirmed that 802.11n just needs an enabler like on Intel when the draft-n stuff rolled out.
1774457387749.png


As for the other system components it's really hard to say if the kernel is that much newer if at all and worth specifically supporting. But at the moment for G5 users and some G4 users with the 7800 GS installing this is something to consider.
 
Last edited:
AFAIK MacPorts does not a mechanism to condition something on client vs server version or specific kernel. So if there are two versions of Tiger with different GL specs, that introduces a problem: either you support lowest version and miss possible gains where newer is supported, or break it for a version with older GL, or add variants for both, but without a mechanism to choose an appropriate one. It is exactly the same issue I have with 10.6.8, where there is a version with a newer GL (“Nvidia”) and older GL (A5).
 
  • Like
Reactions: jktwice
It does in fact have OGL2 HW acceleration and it has 802.11n support. So using, say, PowerFox on a G5 in Tiger is gonna be a lot more usable (but not that much more so. I use PF Intel and while it's awesome you still need to adjust your expectations).

@Jazzzny was curious about this initially and did spin up a quick 10.4.11 Server install and confirmed that 802.11n just needs an enabler like on Intel when the draft-n stuff rolled out.
View attachment 2616715

As for the other system components it's really hard to say if the kernel is that much newer if at all and worth specifically supporting. But at the moment for G5 users and some G4 users with the 7800 GS installing this is something to consider.
Great to have confirmed, I suspected as much from the documentation. Realistically, the number of ports assuming OpenGL acceleration is not high, and in many cases it can be turned off trivially (such as QMPlay2).
802.11n internet is very nice to have, but I don't believe it affects any ports, or we would hear about it even on Leopard and Snow Leopard from users whose hardware doesn't support 802.11n.
The kernel is definitely newer on Tiger Server than Tiger Client - the respective build numbers are reported as 8S165 for PowerPC and 8S2167 for Intel (or Tiger Server) (https://apple.fandom.com/wiki/Mac_OS_X_10.4.11). The question is if any of the fixes for the newer kernel are relevant for building ports, which no one has tested.
The key issue is lack of users who test on Tiger and make pull requests to fix issues (and few even raise issues in the Github thread). We need more active users trying to fix things on Tiger, and dropping Tiger Client and only supporting Tiger Server will make that worse. The advantages of having a larger potential community to propose fixes is greater than the minimal advantages (newer OpenGL and kernel version) Tiger Server provides.
That being said, it would be great to have someone using Tiger Server and seeing if anything builds that won't on Tiger Client.
AFAIK MacPorts does not a mechanism to condition something on client vs server version or specific kernel. So if there are two versions of Tiger with different GL specs, that introduces a problem: either you support lowest version and miss possible gains where newer is supported, or break it for a version with older GL, or add variants for both, but without a mechanism to choose an appropriate one. It is exactly the same issue I have with 10.6.8, where there is a version with a newer GL (“Nvidia”) and older GL (A5).
I agree that variants for both is ideal, but again, someone has to do that on Tiger. I might get to it at some point, but getting JIT working on 10.4 32-bit for UXP browsers is already more than I can handle.
 
Last edited:
Phew that was quite intense. But I believe I finished all the rebuilds. Some minor breakages (mostly archaic stuff) but nothing too bad, pretty much everything still works!

I have mostly rebuilt related stuff by now and identified a few breakages in Gnome-related ports. Those are fixed in recent commits.
 
  • Like
Reactions: Matias_
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.