PPCPorts: the only ports you ever need on a PowerPC

[barracuda156]

I think it is about time to make this more explicit: if you use 10.5.8 or 10.6.8 on some PowerPC hardware, consider switching to PPCPorts. Compatibility with MacPorts is retained, but more stuff actually works (not only development tools, but also GUI apps, multimedia etc.).

Basic info is on the website: https://macos-powerpc.org
For developers: https://github.com/macos-powerpc/powerpc-ports

10.5 in its official release form is supported, primarily for ppc64. I you do not have a G5 or do not need ppc64, choosing 10.6 makes a better sense.

This is not a call-to-testing anymore, I am fairly confident that everything just works.


P. S. If anyone would want to support the project, whether by code contributions or donating, that is gratefully accepted. I cannot post links here, but you may find them on my site and GitHub page.

 

[Doq]

insert cosign here.

barracuda has been doing God's work bringing more recent software to life on the Leopards, and it's been an awesome project to see (and interact with in some moments).

If you're fine with getting your hands a bit dirty and learning a bit around the Terminal, this is the way to have a newer software experience without relegating to a whole new different operating environment.

 

[Forest Expertise]

I also want to thank barracuda156 for the amazing work on over a thousand PowerPC ports. His work is very helpful for Tiger users as well. To benefit from his amazing work on Tiger, do the following:
1. Install Macports from here: https://github.com/macports/macports-base/releases/tag/v2.10.7
2. Download the PowerPC ports repository from here: https://github.com/macos-powerpc/powerpc-ports
Make sure to unzip it and put it into an easy to find directory
3. Edit opt/local/etc/macports/sources.conf to have your path to the downloaded git repository above the rsync://
4. Make sure to sudo port sync. Portindex once you are in your git repository
You should now have access to (unsupported) PowerPC ports on Tiger!

In addition: I have a Powerbook G4 successfully serving binaries with Macports to another 2005 Powerbook G4 over a local network with lighttpd 1.4.79.
It should be accessible to you all here: powerbookg4e.pagekite.me
If you can't get the binary archives to work, let me know and I will try to fix it. This is my first server. Please test but be nice to it.
Pubkey is attached, I had to add a .txt extension so it would upload. You will need to remove that and save as .pem file.
Relevant part of https://trac.macports.org/wiki/howto/ShareArchives2
Add the following to /opt/local/etc/macports/archive_sites.conf

name bonjour
urls http://powerbookg4e.pagekite.me/

A line indicating the location of the public key must also be added to /opt/local/etc/macports/pubkeys.conf. Something like:

/opt/local/share/macports/local-pubkey.pem

This can save a lot of compiling time for people with slow G4e and possibly slow G4 processors. You will need to change versions in Portfiles to match what is in my binary archive for it to download. There are binary available for current claws-mail and at least some versions of all its dependencies.

P.S. If you are good with this sort of thing, build curl in a different Macports prefix and have Macports use that instead of system curl. It will save you having to hunt down source files manually and put them into the correct folder inside distfiles in opt/local

I also try to contribute with code to PowerPC ports. Unfortunately, I know very little so I don't know that I can contribute much of value yet.

 

[barracuda156]

A few notes, not too systematic at this point, but rather have them now anyway:

Installation on top of existing MacPorts
This generally works fine, however config files are not overwritten, so it makes sense to review what is there. Alternatively, delete them prior to installation, and new ones will be written.

X11
1. If you plan to use X11/GTK/wxGTK apps, remove any alternative installation of X11/XQuarts from system prefix. It is a few seconds procedure, nothing needed to clean up manually. See: https://www.xquartz.org/FAQs.html
Unless that is done – at least in my experience – no X11 GUI apps will work.
2. There are three relevant ports of X server (which is needed to run X11 GUI): xorg-server-1.18, xorg-server-legacy and xquartz. xorg-server-1.18 is only needed for Tiger. On 10.5+ use either of the latter. xquartz is much newer, but might not work on some configs. All these can be installed in parallel, but only one can be active at any given time.
3. Upon installation/activation of one of those X server ports, reboot is needed. At least on 10.6.x the first launch of X app may freeze – if it happens, just force-quit the app and launch it again. X11 is not the most robust thing, LOL, but if everything is done correctly, it will work. Unless you build ports locally, just keep X server installed and active, and you avoid most of the headache.

Xcode-using apps on 10.6
Since Xcode is not open-source and there is no Xcode 3.2.6 with complete ppc part, using it to build apps on 10.6.8 on powerpc is hit & miss. Something will build, something won’t, and that also may depend on which Xcode components you replace (3.2.6 is defunct as-is). What works far better generally is building those apps on 10.6.8 x86 (either as universal or ppc-only). There are not many apps which rely on Xcode, thankfully, and those are mostly archaic and seldom useful apps. 10.6.8 on x86 with Rosetta can share apps with 10.6.8 on powerpc (no need to build everything twice).

ppc64 on 10.5
Default config sets ppc as build arch and disabled universal builds. This is a sensible default which fits most cases. However, on a G5 you may instead choose to build for ppc64. (Universal builds are largely non-trivial, and it is simpler to assume it is just broken: build one arch at a time.)
To switch to ppc64, edit /opt/local/etc/macports/macports.conf so that build_arch is set to ppc64 (you may also want to set universal_archs to `ppc ppc64`). Some pre-built ports are here: http://macos-powerpc.org/packages_ppc64

-devel and -legacy ports
Quite a number of ports exist in “normal” and -devel versions. A few also have -legacy subports. Unless you know what you are doing, it is generally safer to avoid -devel versions (unless something of those is installed by default). There are a few exceptions: qt4-mac-devel is fine to use and at least on 10.6 it is, IMO, usually preferable; mplayer-devel can be used normally; isl-devel is used by default by gcc14.
-legacy versions were meant to be used on older systems (which normally includes powerpc ones), however in some cases “normal” versions of ports build and work, which leaves -legacy ones somewhat redundant (for example, mpv).

G5 users on 10.6.8 (or 10.5.8 ppc64)
Consider adding`+G5` in variants.conf inside /opt/local/etc/macports. This will trigger installing optimized versions of gcc and a few other ports (not many, I have added it only for the primary compiler and a few multimedia ports like ffmpeg). This is not required, but presumably can improve performance. Of course, it can also be used manually, as in `sudo port -v install ffmpeg5 +G5`.

 

[barracuda156]

2. Download the PowerPC ports repository from here: https://github.com/macos-powerpc/powerpc-ports
Make sure to unzip it and put it into an easy to find directory
3. Edit opt/local/etc/macports/sources.conf to have your path to the downloaded git repository above the rsync://
4. Make sure to sudo port sync. Portindex once you are in your git repository
You should now have access to (unsupported) PowerPC ports on Tiger!

Is it gonna update the local repo to the current GitHub main? If not, that will be a suboptimal choice (unless, of course, you just want to have a frozen snapshot).
Any of regular sync methods should work: you can add http or rsync link pointing to powerpc-ports.tar (which gets updated regularly) to sources.conf. (Using git sync won’t be too practical.)

 

[barracuda156]

[Primarily] for 10.4 / 10.5 users:

Updates casually break things, so it is expected that sooner or later some port of interest breaks – either due to changes in the code or due to a failure to rebase patches or a similar silly reason. I try to avoid silly breakages for ports which I keep, but nothing is tested for 10.4, and not too much for 10.5. A lot of ports are used from upstream MacPorts directly (it is unfeasible to maintain an overlay for 40k+ ports), and those get broken more often.
So if you want something to keep working, it should be installed and rebuilt on every update (or at least somewhat regularly; most of ports are not updated frequently anyway) – and ideally confirmed to actually work and not just build. This does not require any technical skills and can be done by anyone on a reasonably fast hardware (perhaps you do not want to do this on an iBook G4 for hundreds of ports).
This is probably more important for some niche ports which you may care about – a broken CMake will be noticed pretty soon by someone, but some scientific or engineering software may never get tested (I have kinda fixed most of math ports on 10.6 and a number of ports in science category, but there are no plans to do the same for 10.5, that will require working on this full-time).

 

[Forest Expertise]

Is it gonna update the local repo to the current GitHub main? If not, that will be a suboptimal choice (unless, of course, you just want to have a frozen snapshot).
Any of regular sync methods should work: you can add http or rsync link pointing to powerpc-ports.tar (which gets updated regularly) to sources.conf. (Using git sync won’t be too practical.)

I do recommend updating the local repo to the current Github main reasonably often. I find it easiest to trash the local git and clone it again. It is important to have local git for Tiger users, ideally also for Macports and not just PowerPC ports, so that fallbacks can be accessed by editing portfiles or things like OpenGL 2.0 can be turned off in the portfile. As has been noted, things will be broken on Tiger and being able to edit portfiles locally will be needed to get a working ports setup at this time. Thanks to your amazing work, Snow Leopard users and G5 users on Leopard have a plug and play experience. Tiger is not close to that, but still can get a lot done. Also, if not building against external curl, port sync with rsync generally fails with PowerPC ports.
I don't claim that these are the best ways to do things, but they have allowed me to make massive progress with building useful programs on Tiger, such as claws-mail.

 

[doctor_dog]

I'm late to the party here, but throwing in another "thank you" to barracuda156 for the countless hours spent keeping powerpc ports accessible on these quaint old machines. Not only for that, but also for sharing wisdom and knowledge with the rest of us folks trying to wrap our heads around the inner workings of a platform relatively few others are experts on. I've been "that guy" who thought I knew what I was talking about, only to find out later I in fact did not =). Appreciate the patience in explaining and helping out, definitely would not be able to do any of the Macports stuff I've been able to do without his input and guidance. I really don't know how he's able to do it all, must not sleep much Cheers!

 

[barracuda156]

ideally also for Macports and not just PowerPC ports, so that fallbacks can be accessed by editing portfiles or things like OpenGL 2.0 can be turned off in the portfile. As has been noted, things will be broken on Tiger and being able to edit portfiles locally will be needed to get a working ports setup at this time.

I always have a local overlay on top of my ports and upstream ports. For development that’s essential. (Ideally it should be empty, but normally it is not LOL.)

Snow Leopard users and G5 users on Leopard have a plug and play experience.

That’s rather far from reality, unfortunately, since I usually have to fix something on a daily basis – and there are breakages which keep being postponed indefinitely (either due to lack of time or due to being non-trivial).
But it is probably decent on SL. Not so much on 10.5, but yeah, at least the toolchain actually builds and works (ppc64 was and is broken in upstream forever).

Tiger is not close to that, but still can get a lot done. Also, if not building against external curl, port sync with rsync generally fails with PowerPC ports.

http will probably work? (No need to use https with the site.)

I have no objections against git, it just requires somewhat more effort.
But whatever works is good enough.

 

[Forest Expertise]

I always have a local overlay on top of my ports and upstream ports. For development that’s essential. (Ideally it should be empty, but normally it is not LOL.)



That’s rather far from reality, unfortunately, since I usually have to fix something on a daily basis – and there are breakages which keep being postponed indefinitely (either due to lack of time or due to being non-trivial).
But it is probably decent on SL. Not so much on 10.5, but yeah, at least the toolchain actually builds and works (ppc64 was and is broken in upstream forever).



http will probably work? (No need to use https with the site.)

I have no objections against git, it just requires somewhat more effort.
But whatever works is good enough.

I agree that http will probably work and if Tiger ever gets to a point where it is useable without local git repositories, that will likely be the way to go. Though ideally a bootstrap curl installer would be even better, that way https can be used.
Local git repositories are essential on Tiger at this time, so I am not a fan of using rsync for the macports repo or the PowerPC ports repo. Strictly speaking though, one only needs one overlay repo so I recommended using git for PowerPC ports. With local repositories you can grab older versions, which Tiger needs to do for cmake among other important ports. I usually use git repos for both PowerPC ports and Macports because the convenience in being able to grab older versions outweighs the difficulty of keeping git up to date. I think I have figured out how to add fallbacks to Portfiles more properly, so I expect I can submit some pull requests adding fallbacks for Tiger to PowerPC ports this weekend once I have tested.
Thank you for all you do! I have donated and hope others are donating as well.

 

[barracuda156]

I agree that http will probably work and if Tiger ever gets to a point where it is useable without local git repositories, that will likely be the way to go. Though ideally a bootstrap curl installer would be even better, that way https can be used.
Local git repositories are essential on Tiger at this time, so I am not a fan of using rsync for the macports repo or the PowerPC ports repo. Strictly speaking though, one only needs one overlay repo so I recommended using git for PowerPC ports. With local repositories you can grab older versions, which Tiger needs to do for cmake among other important ports. I usually use git repos for both PowerPC ports and Macports because the convenience in being able to grab older versions outweighs the difficulty of keeping git up to date.

If you use the same repos to add fallbacks, then you also need to resolve merge conflicts? Is there a way to do it conveniently?

I switched to standalone repo from a fork largely due to merge conflicts becoming both too annoying and unsafe (in the worse scenario there are no visible errors on merge, but the code is broken in result).

I think I have figured out how to add fallbacks to Portfiles more properly, so I expect I can submit some pull requests adding fallbacks for Tiger to PowerPC ports this weekend once I have tested.

Currently I have no idea what is a scale of changes 10.4 needs. If some patches turn to be too invasive, we can just make standalone drop-in ports (like libsdl2-snowleopard for x86).

Thank you for all you do! I have donated and hope others are donating as well.

Thank you, always appreciated!

 

[barracuda156]

A note on ports availability:

Generally, an absence of some pre-built port does not imply it is broken on powerpc. There are 40k+ ports in MacPorts presently, and while a number of those are made up by multiple python and perl versions, there are still a lot of unique ports. And while it will be nice to have everything pre-built, that can only be possible, if we get a buildbot which will be running 24/7 and accessible remotely. Until then only a subset of ports will be built (and re-built on updates).

For the same reason any given port from upstream MacPorts may be broken but totally fixable (sometimes trivially). Unless either I build a port or someone else complains that it is broken, we just won’t know it is broken, and there will be no fix available in PPCPorts.

So if you want something specific, and it fails to build – or builds, but fails to work, please open an issue about that. (Admittedly, there is no point to do that for ports which explicitly depend on something known to be broken, like Qt5–Qt6, or Rust, or Golang. If any of these get fixed, it will be a big news LOL. These cases aside, please open issues.)

 

[jktwice]

A note on ports availability:

Generally, an absence of some pre-built port does not imply it is broken on powerpc. There are 40k+ ports in MacPorts presently, and while a number of those are made up by multiple python and perl versions, there are still a lot of unique ports. And while it will be nice to have everything pre-built, that can only be possible, if we get a buildbot which will be running 24/7 and accessible remotely. Until then only a subset of ports will be built (and re-built on updates).

For the same reason any given port from upstream MacPorts may be broken but totally fixable (sometimes trivially). Unless either I build a port or someone else complains that it is broken, we just won’t know it is broken, and there will be no fix available in PPCPorts.

So if you want something specific, and it fails to build – or builds, but fails to work, please open an issue about that. (Admittedly, there is no point to do that for ports which explicitly depend on something known to be broken, like Qt5–Qt6, or Rust, or Golang. If any of these get fixed, it will be a big news LOL. These cases aside, please open issues.)

Buildbot could be some Intel Xserve or even some Mac minis yea? Something that can run Tiger-Snow Leopard preferably and then build against the correct components targeting PPC arch?

We shouldn't need a PPC machine for this but some ports do require Xcode so it's a question worth asking.

 

[barracuda156]

Buildbot could be some Intel Xserve or even some Mac minis yea? Something that can run Tiger-Snow Leopard preferably and then build against the correct components targeting PPC arch?

That might work, with certain constraints: some stuff does not build or run in Rosetta (sbcl, jdk, modern ruby, ghc, perhaps something else).

We shouldn't need a PPC machine for this but some ports do require Xcode so it's a question worth asking.

It will be better than nothing, but MacMini G4 makes a better sense overall, IMO.

 

[waltherstreet]

@barracuda156 , do you know why MacPorts dropped support for Tiger?

 

[barracuda156]

@barracuda156 , do you know why MacPorts dropped support for Tiger?

Technically because those few folks there who are setting the policy decided so.

It could have been a declarative change: not much was working on Tiger anyway, and since nothing was tested (with a few exceptions) for years, it should be expected to be broken. There was hardly any need to deliberately throw away whatever support existed, especially from the base.

These was a discussion on the mailing list, it should be publicly available.

TBH, the change was largely nominal, with the exception of the base. A lot of ports were already broken, for a long time, and nobody cared, including supposed users of Tiger. And ultimately it is users who are responsible: more often than not if an upstream sees an existing demand for their software, they may retain some support for a platform in question and are more favorable to accepting fixes. Mac users seldom bother to use GitHub etc., so they effectively isolate themselves and become invisible to upstreams. So the impression is that macOS on PowerPC is dead for decades, and why bother to keep any code for it or fix related bugs. Look through GitHub issues and try to find how many bugs are being reported for 10.4–10.6. And how many ppl submit them.

 

[barracuda156]

Update for 10.6.8 (ppc native/Rosetta)

P. S. Updated on the website now.

 

[barracuda156]

gcc14 updated to 14.3.0

Some new ports added:

fat: new port in sysutils · macos-powerpc/powerpc-ports@20f408c

Overlay repo with fixes to use with MacPorts on macOS PowerPC - fat: new port in sysutils · macos-powerpc/powerpc-ports@20f408c

github.com

fread: new port, TUI text file reader · macos-powerpc/powerpc-ports@6124fd5

Overlay repo with fixes to use with MacPorts on macOS PowerPC - fread: new port, TUI text file reader · macos-powerpc/powerpc-ports@6124fd5

github.com

sip: new port, a tool to download from GitHub · macos-powerpc/powerpc-ports@9c5c755

Overlay repo with fixes to use with MacPorts on macOS PowerPC - sip: new port, a tool to download from GitHub · macos-powerpc/powerpc-ports@9c5c755

github.com

mastui: update to 0.9.0 · macos-powerpc/powerpc-ports@c8e866b

Overlay repo with fixes to use with MacPorts on macOS PowerPC - mastui: update to 0.9.0 · macos-powerpc/powerpc-ports@c8e866b

github.com

among others.

 

[Matias_]

For those who are interested, I have setup a 32bit PPCPorts binary repository for 10.5.8. Mainly useful for G4 users and also G5 users that can't or don't want to use PPC64.

Currently approximately 1000 packages are available: https://kemonomimi.nl/ppcports/

 

[barracuda156]

For those who are interested, I have setup a 32bit PPCPorts binary repository for 10.5.8. Mainly useful for G4 users and also G5 users that can't or don't want to use PPC64.

Currently approximately 1000 packages are available: https://kemonomimi.nl/ppcports/

Oh, nice, I can update instructions for config files, so that users can use your pem key and archives.

BTW, which protocols are supported besides https? Http? Rsync?

 

[Matias_]

Only HTTP and HTTPS at the moment. I might look into Rsync if it proves to be useful, I already use it to upload the ports to my webserver but that is just over SSH.

 

[barracuda156]

Only HTTP and HTTPS at the moment. I might look into Rsync if it proves to be useful, I already use it to upload the ports to my webserver but that is just over SSH.

If you have time, could you try building py312-awscli2 (a tool to access S3-compatible online storage) and FastAnime (the latter gonna require a fix to a dependency which I pushed today, so gonna need a sync in an hour or so).

Upd. I have pushed new ports sources archive with a relevant fix for 10.5 for py-pycryptodomex.

 

[Nightphase]

I also want to thank barracuda156 for the amazing work on over a thousand PowerPC ports. His work is very helpful for Tiger users as well. To benefit from his amazing work on Tiger, do the following:
1. Install Macports from here: https://github.com/macports/macports-base/releases/tag/v2.10.7
2. Download the PowerPC ports repository from here: https://github.com/macos-powerpc/powerpc-ports
Make sure to unzip it and put it into an easy to find directory
3. Edit opt/local/etc/macports/sources.conf to have your path to the downloaded git repository above the rsync://
4. Make sure to sudo port sync. Portindex once you are in your git repository
You should now have access to (unsupported) PowerPC ports on Tiger!

In addition: I have a Powerbook G4 successfully serving binaries with Macports to another 2005 Powerbook G4 over a local network with lighttpd 1.4.79.
It should be accessible to you all here: powerbookg4e.pagekite.me
If you can't get the binary archives to work, let me know and I will try to fix it. This is my first server. Please test but be nice to it.
Pubkey is attached, I had to add a .txt extension so it would upload. You will need to remove that and save as .pem file.
Relevant part of https://trac.macports.org/wiki/howto/ShareArchives2
Add the following to /opt/local/etc/macports/archive_sites.conf

name bonjour
urls http://powerbookg4e.pagekite.me/

A line indicating the location of the public key must also be added to /opt/local/etc/macports/pubkeys.conf. Something like:

/opt/local/share/macports/local-pubkey.pem

This can save a lot of compiling time for people with slow G4e and possibly slow G4 processors. You will need to change versions in Portfiles to match what is in my binary archive for it to download. There are binary available for current claws-mail and at least some versions of all its dependencies.

P.S. If you are good with this sort of thing, build curl in a different Macports prefix and have Macports use that instead of system curl. It will save you having to hunt down source files manually and put them into the correct folder inside distfiles in opt/local

I also try to contribute with code to PowerPC ports. Unfortunately, I know very little so I don't know that I can contribute much of value yet.

I just tested on my PowerMac G4 MDD running Tiger, it works fine. It's nice to finally get updated gcc7 in minutes instead of 20+ hours XD. It's sad that they dropped Tiger from MacPorts

 

[Forest Expertise]

I just tested on my PowerMac G4 MDD running Tiger, it works fine. It's nice to finally get updated gcc7 in minutes instead of 20+ hours XD. It's sad that they dropped Tiger from MacPorts

Thank you so much for testing! Glad it saved you a day of compilation time. I will try to improve the uptime on the server (a PowerBook G4).
Dropping Tiger from Macports doesn't seem like a huge tragedy - the people who fixed things the most are almost all on this forum anyway (such as barracuda156, kencu, and glebm. There are probably more amazing people I am forgetting). And this hasn't been the first time Tiger got dropped if you look deep enough into the past. If I can find the time and Macports stops releasing every other week I can try to get barracuda156's patch to restore Tiger support working on 2.11.5. Idk if they added any features making it worth the switch.

 

[barracuda156]

Dropping Tiger from Macports doesn't seem like a huge tragedy

As long as nothing is tested and fixed, there is little to no difference if support is retained nominally. And with the exception of legacy-support library, pretty much nothing was, for years. So yeah, I agree, it does not change anything much practically.

If I can find the time and Macports stops releasing every other week I can try to get barracuda156's patch to restore Tiger support working on 2.11.5.

LOL, that has been insane with 2.11.x. And no, perhaps there is little practical need to upgrade. (I mean, I am on 2.11.5 on 10.6 and 2.11.4 on 10.5, however I am not aware of any radical improvements. In any case, that is by far not the most impactful factor for older OS.)