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.
PPCPorts: the only ports you ever need on a PowerPC
- Thread starter barracuda156
- Start date
- Sort by reaction score
Smithwick’s
macrumors regular
Thinking of switching my PBG4 over to stock 10.5.8 as 10.6.8a has a few bumps that make it troublesome on a portable. How is the functionality of PPCPorts on Leopard? It's genuinely a game changer for my SL machines and I'd love to keep that functionality with the solid base that Leopard is on a late G4.
PowerPC builds are normally tested only on 10.6.8, so there is no guarantee every port builds at an arbitrary moment. That implies that updates can break something, though nothing prevents you from postponing an update of a failing port until it is fixed.
There are some ports that will not build or work on 10.5 by design, and that is unlikely to change. Perhaps not many of what we have (viu/fastanime, radian, whatever uses libdispatch and has no fallback, etc.).
Some ports may work but have sub-optimal functionality (though in some cases it can also be reverse, if a given software is old and was designed for Leopard). Presumably those which use libdispatch but have a fallback for 10.5 (say, SBCL compiler); perhaps Qt4 (Cocoa only supported in qt4-mac-devel on 10.6); I recall mlterm with Cocoa does not work on 10.5.
Otherwise it is expected to work.
Notice: I have updated a lot of multimedia ports today, please notify if something does not build.
If you have something local that links to dav1d/libheif/libvpx/openjph/svt-av1, it will likely need to be rebuilt.
If you have something local that links to dav1d/libheif/libvpx/openjph/svt-av1, it will likely need to be rebuilt.
DBAlex
macrumors regular
Can anyone reccomend any package managers for PPC ports on Leopard? I used to use Fink and I’ve seen Leopard.sh
MacPorts is very good but believe it compiles everything from source? Are the precompiled packages stored anywhere so I can run MacPorts with pre-recompiled binaries?
MacPorts is very good but believe it compiles everything from source? Are the precompiled packages stored anywhere so I can run MacPorts with pre-recompiled binaries?
As odd as it feels to recommend my own LOL, I think PPCPorts is the best at the moment. (This does not mean, of course, that every given port is at least as good or better as with alternatives.)
Both Fink and pkgsrc will need work just to get them running to begin with. pkgsrc is worth looking at if a) you use *BSD or Linux more than macOS and b) have motivation and a lot of time to fix macOS part. dreckly is a more portable fork of pkgsrc, but last time I tried it also failed out-of-the-box on macOS (on Linux it will work with less pain than MacPorts).
I have some for ppc64, but not many and largely lagging behind the repo. If you can use 10.6.8, more or less everything is available pre-compiled.
There are some user-provided builds for ppc32 on Leopard, check this thread. I am not aware of the status of those though.
To my knowledge there does not exist any solution presently which will allow you to install everything pre-built and up-to-date for 10.5.
Matias_
macrumors regular
I last updated my binaries 3 days ago so they should be reasonably up to date I think.
Can second that they are in good shape, they saved a lot of time when getting gcc13. Thank you for keeping them available.
One note - Matias_ used isl-devel instead of isl, so you will need to have isl-devel active instead of isl to not have broken binaries. It took me a while to figure that one out.
@Matias_ are there any other cases where you used the -devel port instead of the regular that come to mind?
Matias_
macrumors regular
Not that I'm aware of. There are some ports for which I built both the regular and -devel version. Of course only one can be active so the other might not always be up to date.
I don't think I intentionally chose isl-devel, it was probably pulled in by MacPorts at some point. The reason I have regular isl as well is because I recall that the old gcc4.8 needed it and I thought that would be useful to have for TenFourFox.
isl-devel is used by default in my ports. Why isl was just not updated was to keep compatibility with MacPorts: old gcc do not build with modern isl, so if I make a new isl24 (or whichever) port to use with gcc <7, I will need to bring all those into PPCPorts. It is impractical; far easier to use isl-devel for gcc versions which are already maintained here.
There are no specific instructions re isl since I assume nobody besides developers will deliberately install isl at all, and developers are expected to read portfile code and comments to figure out what’s up.
And yes, please, build all packages to be distributed with default settings (non-default variants from unmodified port files are okay) and default dependency chain, otherwise we get a mess on user-end which will be very hard to debug.
Re -devel ports: perhaps the only non-conforming choice is qt4-mac-devel, which I do prefer over non-devel port, including for pre-built packages. However, these two are drop-ins in most cases (and when they are not, portfile will explicitly require the right one).
Of course, any end-user port with no dependents can be used in -devel version with no consequences. Say, I use mplayer-devel normally.
And yes, please, build all packages to be distributed with default settings (non-default variants from unmodified port files are okay) and default dependency chain, otherwise we get a mess on user-end which will be very hard to debug.
Re -devel ports: perhaps the only non-conforming choice is qt4-mac-devel, which I do prefer over non-devel port, including for pre-built packages. However, these two are drop-ins in most cases (and when they are not, portfile will explicitly require the right one).
Of course, any end-user port with no dependents can be used in -devel version with no consequences. Say, I use mplayer-devel normally.
Having said that, I don’t like the current state of gccs handling. The plan is to remove all archaic versions, keeping a single gcc (no digits) as the main compiler plus gcc10-bootstrap as unavoidable step. (For support of gcj and D there may be needed a full gcc10, if Iain releases such a version.)
All the rest should go, and together isl can be updated.
All the rest should go, and together isl can be updated.
DBAlex
macrumors regular
Thanks for the advice, I will give PPCPorts a go then on Leopard. Just can't imagine how long some of these packages would take to compile on a G5, even a Quad!
I do plan to try out Snow Leopard at some point.
Is Alpha 5 pretty stable?
Aside of a few ports, like gcc, guile2/guile3, mercury, mongodb, vtk, mpich and openjdk8, it's tolerable. (On the Quad gcc and mpich are fine.)
Not many are that outrageous with compile times, IMO. Also most of huge ports are rather of niche interest. Probably I am the only one who ever compiled mercury or vtk for macOS powerpc LOL
Local networking has issues, otherwise yes, it is fine as the main system. (I recommend to have 10.5 or 10a190 as a back-up one still, minimal partition suffices.)
Please don't assume we're all geeks here just because we use old hardware, OSs and software! What we need is a .dmg and instructions.
Believe me, I'll NEVER touch Terminal again, that **** don't use no Vaseline!
A useful project would be putting reverse action into Terminal, a rewind button before I ****ed it up!
OpenCoreLegacy has done amazing things for Intel users. Part of the amazement is its simplicity. Even I could install it!
Frankly, I'm more than disappointed in Apple. Hardly anybody needs their thinner, lighter, faster sales model. I scrunched after USB-C.
And now, Trump. Timmy loves him and is spending MY money on all Orangeman's dingbattery. I'll never buy a new Apple product again.
We all can see how long Steve's computers last. 2015 was the last good year.
Believe me, I'll NEVER touch Terminal again, that **** don't use no Vaseline!
A useful project would be putting reverse action into Terminal, a rewind button before I ****ed it up!
OpenCoreLegacy has done amazing things for Intel users. Part of the amazement is its simplicity. Even I could install it!
Frankly, I'm more than disappointed in Apple. Hardly anybody needs their thinner, lighter, faster sales model. I scrunched after USB-C.
And now, Trump. Timmy loves him and is spending MY money on all Orangeman's dingbattery. I'll never buy a new Apple product again.
We all can see how long Steve's computers last. 2015 was the last good year.
I don’t really understand what that would even mean in this case. Even if we assume away that it gonna take enormous amount of time, what is the desired outcome? Normally dmgs are used to installs self-sufficient apps. Packaging every app that way implies that there will be numerous copies of every library and framework. That’s a waste of diskspace, for systems which already cannot boast huge internal storage. Packaging everything per-component will make it harder to install for users – instead of a single command you will need to click through GUI installer for every library, which are hundreds of. Making a single gigantic bulk package will gonna satisfy nobody, since that requires identical preferences for all users, which is clearly not the case even remotely.
Smithwick’s
macrumors regular
Uhhhh... You good? Terminal can definitely mess things up but barracuda & co have provided some extremely clear guides both in this thread and on his website on how to use PPCPorts. It isn't exactly rocket science and I'm not sure how much clearer it could be.
I think we should advance a different argument: regardless of whether what we have is convenient or not, there is no sensible alternative way. Which is why all existing package managers are essentially CLI-based.
It is perfectly possible to provide a single app as a dmg. It becomes a different story when there are hundreds of apps.
srp
macrumors regular
All of that being said, wasn't there a GUI project for MacPorts? Wouldn't we be able to get that working?
I don't necessarily want to say we should expect users to NEVER use a Terminal, but I think about Leopard, where there is no default archive repository and you have to add the community repo manually. Before I knew there even was a community repo, I spent probably 6 hours compiling stuff from scratch that already had a package available.
So while we should still set the expectation that, yeah, you're gonna need some Terminal knowledge, it wouldn't hurt to fix up a GUI client for fetching and installing ports. Not sure how feasible something like that is.
I think we can all admit that this community is lacking in the information department. There's a lot of tribal knowledge stuff that we expect users to be able to figure out. I've been working on a GitHub repository with a series of Markdown documents hosting a bunch of tribal knowledge, as well as my dotfiles and common scripts I use, and a comprehensive tutorial on how to setup and install MacPorts is included in that.
I don't necessarily want to say we should expect users to NEVER use a Terminal, but I think about Leopard, where there is no default archive repository and you have to add the community repo manually. Before I knew there even was a community repo, I spent probably 6 hours compiling stuff from scratch that already had a package available.
So while we should still set the expectation that, yeah, you're gonna need some Terminal knowledge, it wouldn't hurt to fix up a GUI client for fetching and installing ports. Not sure how feasible something like that is.
I think we can all admit that this community is lacking in the information department. There's a lot of tribal knowledge stuff that we expect users to be able to figure out. I've been working on a GitHub repository with a series of Markdown documents hosting a bunch of tribal knowledge, as well as my dotfiles and common scripts I use, and a comprehensive tutorial on how to setup and install MacPorts is included in that.
It is probably as easy as to throw the task to Claude (provided one has a suitable subscription), asking to make a python TUI with Textual, for example, or ruby one with rcurses. Both do not require compiling and generally should work out-of-the-box (i.e. no special testing on powerpc needed). Both have libraries to enable fetching online content. If the app will be able to browse existing ports and display info on them, I will use it myself too (not for installing anything, just to look-up without a browser).
There are a number of fuzzy-search apps which can be used with it too (`fnf`, `sentaku`, maybe `pick`).
DBAlex
macrumors regular
Thanks for the advice. I'll try and partition my SSD at some point and give Snow Leopard a go as well as Sorbet Leopard.
Also would like to try some form of Linux at some point, I remember when I had my other G5 Fienix was supposed to run well some maybe time to give that a try.
Smithwick’s
macrumors regular
Unfortunately Fienix is down for the count at the moment. Not being updated + the repos are broken. I'd recommend just going with straight Debian. Check out that thread for some more info. Works like a champ on my G5.
I tried using MacPorts on a Leopard 10.5.8 Intel VM to install gcc15 but it failed at
So now I'm trying PPCPorts on Leopard 10.5.8 Quad G5.
The instructions at https://macos-powerpc.org don't say what to do after step 3.
I tried this:
So then I tried this:
So now I can do this:
I will leave it running overnight.
libomp.So now I'm trying PPCPorts on Leopard 10.5.8 Quad G5.
The instructions at https://macos-powerpc.org don't say what to do after step 3.
I tried this:
Code:
JoeG5:~ joevt$ sudo port list
Warning: Can't open index file for source: rsync://macos-powerpc.org/macos-powerpc/PPCPorts/powerpc-ports.tar
Warning: Can't open index file for source: rsync://rsync.macports.org/macports/release/tarballs/ports.tar.gz
Error: listing all ports failed: No index(es) found! Have you synced your port definitions? Try running 'port selfupdate'.So then I tried this:
Code:
JoeG5:~ joevt$ sudo port selfupdate
---> Checking for newer releases of MacPorts
MacPorts base version 2.12.1 installed,
MacPorts base version 2.12.1 available.
---> MacPorts base is already the latest version
---> Updating the ports tree
The ports tree has been updated.
All installed ports are up to date.So now I can do this:
Code:
JoeG5:~ joevt$ sudo port install gcc15
Warning: archive_sites.conf: no urls set for macports_archives
---> Computing dependencies for gcc15
The following dependencies will be installed:
autoconf
...
zstd
Continue? [Y/n]: Y
---> Fetching archive for gcc_select
---> Installing gcc_select @0.1_10
---> Activating gcc_select @0.1_10
---> Cleaning gcc_select
---> Fetching archive for gcc10-bootstrap
---> Archive not available for gcc10-bootstrap, building locally
---> Fetching distfiles for gcc10-bootstrap
Attempting to fetch http://distfiles.macports.org/gcc/gcc-10.5.0.tar.gz
---> Verifying checksums for gcc10-bootstrap
---> Extracting gcc10-bootstrapI will leave it running overnight.