MB 1,1-7,1 Tigerports.com - Entire MacPorts Infrastructure Revived For Mac OS X 10.4

[alex_free]

http://tigerports.com

Imagine if tiger was still supported by MacPorts, thats exactly the experience this provides.

Tigerports is not just a fork of MacPorts. It is a recreation of the entire MacPorts infrastructure that is tailored to our favorite OS. TigerPorts provides:

Tiger orientated ports tree focused on software that works on Tiger.

Tiger orientated base, configured in source to use tigerports.com.

Tiger orientated infrastructure, allows hosting tigerports.com on a Debian VPS rather then a Mac like MacPorts has it. This includes numerous improvements to the sync scripts, adds binary package signing management, and includes a setup script to recreate my server.

Tarball releases to install TigerPorts from source on your Mac, same as official MacPorts (PKG installer is WIP).

The tigerports.com rsync server, which syncs with the Tiger orientated ports tree every 15 minutes, exactly like real MacPorts. Any pull requests merged there will be available in no later then a quarter hour to all TigerPorts users via sudo port selfupdate.

The tigerports.com http server, which serves distfiles.

Security is kept the same, just not managed by MacPorts. The ports tree, portindex, and binary packages served directly by tigerports.com are all signed.

HOW YOU CAN HELP

BINARY PACKAGES
TigerPorts is designed to NOT delete compiled binary packages by default (you can of course change this by editing /opt/local/etc/macports/macports.conf and changingportclean notoportclean yes, or you can just periodically runsudo port clean). As you use TigerPorts (unless you change macports.conf as explained previously explained), you will keep a cache of compiled software binaries at/opt/local/var/macports/software. You will also get the distfiles (sources used to build) populated at/opt/local/var/macports/distfiles`. The goal is for all of these to populated on the tigerports.com server, so please submit these 2 folders to me if the software is not yet available as binaries on the tigerports.com server so others can skip building from source!

PORTS TREE
As of the initial release, the source tree is essentially what the official MacPorts one was on 1/31/2025, right before Tiger support was officially dropped. This provides us with a base that we can work on and improve.

There are many community fixes, projects like PPCPorts, etc that I want implemented! Please, open a pull request with your improvements!

I am also OK with downgrading/upgrading individual ports as needed. Have a need for a newer version, or fixes for a new port? Submit it! Notice something is currently impossible to build at the current version, but an older one works? Submit it! I last used macports on Tiger extensively in 2021 and a ton of ports worked. I’m fine reverting to those port files on a case by case basis if its tested to work with the rest of the tree.

BE A USER
Spread the word! Tiger will never die. Report issues, suggest improvements, enjoy it.

Greetz @kencu @barracuda156 @Forest Expertise

 

[barracuda156]

BINARY PACKAGES
TigerPorts is designed to NOT delete compiled binary packages by default (you can of course change this by editing /opt/local/etc/macports/macports.conf and changingportclean notoportclean yes, or you can just periodically runsudo port clean). As you use TigerPorts (unless you change macports.conf as explained previously explained), you will keep a cache of compiled software binaries at/opt/local/var/macports/software.

This is redundant. Compiled ports are always saved in /opt/local/var/macports/software, that’s what gets activated (it must exist). On the other hand, cleaning ports after successful compilation is the correct default: one would want to change that only when developing (even then it is unneeded in most cases). Please do not disable autoclean, otherwise users get gigabytes of junk on the hard drive (and assuming Tiger is meant for weak hardware, likely iBooks do not have 600 GB SSDs).

You will also get the distfiles (sources used to build) populated at/opt/local/var/macports/distfiles`

This is the default when building from source, I think, and there is no reason to store distfiles otherwise (that would require separate downloads, and what is one gonna do with distfiles anyway? when building from source it makes sense to avoid re-fetching the same thing many times).

PORTS TREE
As of the initial release, the source tree is essentially what the official MacPorts one was on 1/31/2025, right before Tiger support was officially dropped. This provides us with a base that we can work on and improve.

There are many community fixes, projects like PPCPorts, etc that I want implemented! Please, open a pull request with your improvements!

This is only my opinion, not an attempt to convince anyone, but I think the right thing is to automate that you always get ports from PPCPorts when they exist and fallback to official ones otherwise (this of course implies no pegging to archaic tree). Or if @Forest Expertise has his tree for Tiger, just use that directly.

Fixing ports tree to some old snapshot is fine, as long as it is actually fixed. Inviting PRs onto that is not very practical. That assumes someone is gonna do enormous work, on the ongoing basis, which will largely duplicate both PPCPorts and MacPorts upstream.

I am also OK with downgrading/upgrading individual ports as needed. Have a need for a newer version, or fixes for a new port? Submit it! Notice something is currently impossible to build at the current version, but an older one works? Submit it! I last used macports on Tiger extensively in 2021 and a ton of ports worked. I’m fine reverting to those port files on a case by case basis if its tested to work with the rest of the tree.

Start off PPCPorts, then you only need to fix what is broken specifically for Tiger, instead of fixing all that plus everything broken for powerpc, plus everything broken for compiling with gcc, plus everything broken for legacy macOS in general.

But maybe @Forest Expertise or/and @glebm have better ideas.

 

[alex_free]

This is redundant. Compiled ports are always saved in /opt/local/var/macports/software, that’s what gets activated (it must exist). On the other hand, cleaning ports after successful compilation is the correct default: one would want to change that only when developing (even then it is unneeded in most cases). Please do not disable autoclean, otherwise users get gigabytes of junk on the hard drive (and assuming Tiger is meant for weak hardware, likely iBooks do not have 600 GB SSDs).



This is the default when building from source, I think, and there is no reason to store distfiles otherwise (that would require separate downloads, and what is one gonna do with distfiles anyway? when building from source it makes sense to avoid re-fetching the same thing many times).



This is only my opinion, not an attempt to convince anyone, but I think the right thing is to automate that you always get ports from PPCPorts when they exist and fallback to official ones otherwise (this of course implies no pegging to archaic tree). Or if @Forest Expertise has his tree for Tiger, just use that directly.

Fixing ports tree to some old snapshot is fine, as long as it is actually fixed. Inviting PRs onto that is not very practical. That assumes someone is gonna do enormous work, on the ongoing basis, which will largely duplicate both PPCPorts and MacPorts upstream.



Start off PPCPorts, then you only need to fix what is broken specifically for Tiger, instead of fixing all that plus everything broken for powerpc, plus everything broken for compiling with gcc, plus everything broken for legacy macOS in general.

But maybe @Forest Expertise or/and @glibm have better ideas.

Thanks for the response!

By disabling autoclean, we can amass more binaries (if people submit them, but on the website it does explain that you can either occasionally manually exec sudo port clean, or renable it in the config file with instructions). My mac mini G4 only has a 40GB HDD rn, so I'm well aware of the space these take up. Perhaps this can be reversed, then a script can be shipped in the release tarball/tigerports-base that just modifies macports.conf. to disable autoclean. The main idea with this is people will want to build different things, and it can speed up coverage for pre-built port binaries since we have a relatively frozen tree currently.

You are correct that distfiles are saved and not autocleaned by default. I only mention it because if someone wants to submit binaries for upload to the tigerports.com server, I want the distfiles as well. I serve those there, and tigerports by default has the site configured for distfiles. If for some crazy reason these older distfiles get removed from the other mirrors, they are saved and still available. Also, macports serves them, so I want to as well.

Its my opinion that it is even more unmaintainable for Tiger specifically to use current MacPorts port tree, which is removing tiger based patches from ports and moves too fast to keep up. I am well aware that even at my snapshot (1/31/2025) that I am using as a base tiger wasn't a tier 1 OS. But even in 2021 alot of stuff worked. And the snapshot is the last before it was officially anounced that 10.4 wasnt supported.

What I think is perhaps best for Tiger specifically (not so much 10.5 and 10.6) is a frankenstien of anything powerpc ports can provide for Tiger merged with this snapshot. From the PPCports site it seems like its focused mostly on 10.6/10.5.8, but anything that doesnt need to reinvent the wheel is of course extremely ideal. Using PPCports as an upstream in this way seems the most maintainable. This seems most desirable, a known collection of software that builds on tiger, with a more obtainable goal of broad pre-compiled binary support due to much less movement. I can just run my machines compiling packages.

As for updating things not covered by ppc ports, we dont need the latest or to track everything. Someone needs version x.y.z as a dependency to build the newest whatever, that can be pull requested in. It's not much if it builds as is to pull it from MacPorts, maybe sliglty modify some dependencies or pull those all in to. They are just folders after all with portfiles. I'm also fine if thats a one off. I'd rather it be done in a way like this that doesn't risk breaking multiple ports all the time, every time its merged with macports upstream. especially with the state of MacPorts not supporting and actively deleting existing tiger fixes/patches (which is of course understandable).

Theres also really popular ports that everyone wants (i.e. git, gcc14, curl, openssl, etc.) which can be focused on. I plan on trying to do so but I'm mostly focused on getting some binaries made right now. Perhaps when I get more build machines/hardware.

Perhaps an overlay is ideal. One idea could be to have an automatic setup that pulls macports ports, the ppc overlay on top as a merge, and serve that as a complete ports tree. I think both ideologies have their advantages and disadvantages of course. There could even be two branches. 'stable' and 'nightly' or something, where nightly would be what I described merging macports+ppc ports overlay but much less available precompiled software for obvious reasons and 'stable' can be the other way. No reason that cant be done.

By the way, if anything can be of use here of what I've done with the infrastructure stuff for 10.5/10.6 or whatever use it. I even figured out how to handle serving the pre-built portindexes so that you dont need to run that on powerpc hardware, alas it will be implemented in v1.0.6.

Nothing is set in stone. I'm open to any and all suggestions, I've been really out of the loop with stuff for a few years now so I appreciate all feedback.

 

[barracuda156]

By disabling autoclean, we can amass more binaries

You need archives from "software", not build artifacts from build dirs. Archives from "software" are credibly distributable (and can be installed directly). Build artifacts are not.

You are correct that distfiles are saved and not autocleaned by default. I only mention it because if someone wants to submit binaries for upload to the tigerports.com server, I want the distfiles as well. I serve those there, and tigerports by default has the site configured for distfiles. If for some crazy reason these older distfiles get removed from the other mirrors, they are saved and still available. Also, macports serves them, so I want to as well.

It is always nice to have an extra hosting. MacPorts keeps them because upstreams can vanish. (Occasionally they actually do.)

Its my opinion that it is even more unmaintainable for Tiger specifically to use current MacPorts port tree, which is removing tiger based patches from ports and moves too fast to keep up. I am well aware that even at my snapshot (1/31/2025) that I am using as a base tiger wasn't a tier 1 OS. But even in 2021 alot of stuff worked. And the snapshot is the last before it was officially anounced that 10.4 wasnt supported.

Snapshot is a valid approach for whomever is satisfied with more predictability (and less work, which is not a small deal in this case) at the cost of security and working web stuff.

That I think is perhaps best for Tiger specifically (not so much 10.5 and 10.6) is a frankenstien of anything powerpc ports can provide for Tiger merged with this snapshot.

I have doubts it can work this way, but anyone is free to try, of course. (In a sense it will likely start breaking things, which undermines the whole point of snapshot.)

From the PPCports site it seems like its focused mostly on 10.6/10.5.8,

It is, but fixes needed for 10.5/10.6 is a subset of fixes needed for 10.4.

but anything that doesnt need to reinvent the wheel is of course extremely ideal. Using PPCports as an upstream in this way seems the most maintainable. This seems most desirable, a known collection of software that builds on tiger, with a more obtainable goal of broad pre-compiled binary support due to much less movement. I can just run my machines compiling packages.

As for updating things not covered by ppc ports, we dont need the latest or to track everything.

It’s more about coherency of everything than latest versions. While neither MacPorts nor my ppcports guarantee that every port builds with its dependencies at any given time, at least to some extent it gets tested. Obviously, nobody ever tested a combo of ports from ppcports and some arbitrary old snapshot of MacPorts tree. Someone has to, for it to work.

 

[alex_free]

You need archives from "software", not build artifacts from build dirs. Archives from "software" are credibly distributable (and can be installed directly). Build artifacts are not.



It is always nice to have an extra hosting. MacPorts keeps them because upstreams can vanish. (Occasionally they actually do.)



Snapshot is a valid approach for whomever is satisfied with more predictability (and less work, which is not a small deal in this case) at the cost of security and working web stuff.



I have doubts it can work this way, but anyone is free to try, of course. (In a sense it will likely start breaking things, which undermines the whole point of snapshot.)



It is, but fixes needed for 10.5/10.6 is a subset of fixes needed for 10.4.



It’s more about coherency of everything than latest versions. While neither MacPorts nor my ppcports guarantee that every port builds with its dependencies at any given time, at least to some extent it gets tested. Obviously, nobody ever tested a combo of ports from ppcports and some arbitrary old snapshot of MacPorts tree. Someone has to, for it to work.

I see, I'm gonna put out a tigerports-base update to address these concerns with autoclean and to use downloaded portindex from the server, rather then having the machine do this on sudo port sync.

The way I see it, the ports tree can be approached 3 different ways:

OPTION 1: 1/31/2025 snapshot + fixes (I just fixed gawk for example:https://github.com/alex-free/tigerports-ports/commit/e42343b0d3c52291cff4edc2de192c9ccdf642e5). Others/myself are free to update any ports individually after testing said changes.

OPTION 2: 1/31/2025 snapshot + direct integration of PPCPorts overlay as PART of the source tree. PPCPorts would be the 'upstream'. This could temporarily break things but as I submit my fixes to PPCPorts and test stuff it can get just as stable as option 1.

OPTION 3: MacPorts ports + direct integration of PPCPorts overlay as PART of the source tree. This is the most unstable as we are basically pulling in 2 different upstreams, both of which are not directly targeting tiger. The way this would be done is test a port, if broken refer to any patches/workarounds in the 1/31/2025 snapshot, reintegrate them if possible/update them. Even if this is done, it would be updated much less then the actual macports tree to try to create a decent amount of binaries. Perhaps pull macports-ports every 3 months unless needed more often.

Option 2 or Option 3 is the way forward I believe. But why not both? Why not host 2 different ports tree branches on github. Option 2 can be the 'stable' one, Option 3 can be the 'unstable' (like Debian kind of). 2 different installers could be on Tigerports.com, configured to either branch of the ports tree. Option 3 could even be in a way an 'upstream' of option 2 perhaps.

Either way, it makes sense to start submitting my fixes to PPCPorts. I have a fast (for Tiger) intel machine, a (for a G4) very fast mac mini, and I'm considering a PowerMac G5. I am serious about making this a real platform.

But what do you think? Nothing is set in stone. What makes the most sense?

 

[Forest Expertise]

I see, I'm gonna put out a tigerports-base update to address these concerns with autoclean and to use downloaded portindex from the server, rather then having the machine do this on sudo port sync.

The way I see it, the ports tree can be approached 3 different ways:

OPTION 1: 1/31/2025 snapshot + fixes (I just fixed gawk for example:https://github.com/alex-free/tigerports-ports/commit/e42343b0d3c52291cff4edc2de192c9ccdf642e5). Others/myself are free to update any ports individually after testing said changes.

OPTION 2: 1/31/2025 snapshot + direct integration of PPCPorts overlay as PART of the source tree. PPCPorts would be the 'upstream'. This could temporarily break things but as I submit my fixes to PPCPorts and test stuff it can get just as stable as option 1.

OPTION 3: MacPorts ports + direct integration of PPCPorts overlay as PART of the source tree. This is the most unstable as we are basically pulling in 2 different upstreams, both of which are not directly targeting tiger. The way this would be done is test a port, if broken refer to any patches/workarounds in the 1/31/2025 snapshot, reintegrate them if possible/update them. Even if this is done, it would be updated much less then the actual macports tree to try to create a decent amount of binaries. Perhaps pull macports-ports every 3 months unless needed more often.

Option 2 or Option 3 is the way forward I believe. But why not both? Why not host 2 different ports tree branches on github. Option 2 can be the 'stable' one, Option 3 can be the 'unstable' (like Debian kind of). 2 different installers could be on Tigerports.com, configured to either branch of the ports tree. Option 3 could even be in a way an 'upstream' of option 2 perhaps.

Either way, it makes sense to start submitting my fixes to PPCPorts. I have a fast (for Tiger) intel machine, a (for a G4) very fast mac mini, and I'm considering a PowerMac G5. I am serious about making this a real platform.

But what do you think? Nothing is set in stone. What makes the most sense?

Just catching up with this now. 3 is by far the best option, you could likely even pull my binaries from powerbookg4e.pagekite.me and save yourself some build time - though if you want to do clean builds there is an argument for that. I rarely deactivate everything before building, although that is best practice, because it takes hours on my hardware. If you have hardware you could automate as a buildbot, that would be amazing.
Option 3 also gets us all working on the same sources, especially if you start from the PPCports base that works on tiger: https://github.com/macos-powerpc/ppcports-base/tree/tiger_upd you could probably cherry-pick the commit restoring 10.4 support and use that to get the modern PowerPC Ports base working on Tiger. This is the best long term solution, because the more people who get fixes for Tiger into PowerPC ports, the better it will be. I could certainly use the help - PowerPC ports for Tiger is in better shape than I think Macports ever was at the moment, but I do struggle to keep up with breakages so I would really appreciate other people pitching in.
Keep in mind @barracuda156 has been very kind about letting Tiger have fallbacks where needed - this may end up being needed for glib2 and gobject-introspection because python-gobject3 bindings do not work with the modern versions (later than 2.79 for Glib2) on Tiger. I still think fixing the software is better than a fallback in that case, but I haven't found a fix yet.

If you also want to pursue option 2, it may be worth pulling PowerPC Ports fixes from here: https://github.com/macos-powerpc/powerpc-ports/releases/tag/2026.04 instead of the most recent PowerPC ports commit.
There have been some changes since that point which may be problematic to integrate into your project.
1. The breaking of python bindings for GTK happened after that point, with the update of glib2 and gobject-introspection.
2. Portgroups had some changes, which cause different assumptions than the base made in early 2025. Also, the cmake Portgroup brought in an rpath related argument which broke at least one port which I fixed, but it may have broken others I am unaware of.
3. We switched to gcc16, which seems to be working pretty well. It takes longer to build things than gcc14, and takes longer to build. Theoretically it is optimizing code better to make up for this. There are tradeoffs to be considered. Also, there are a couple of issues I brute forced through without checking with upstream in fixing the build. Checking with upstream is on my agenda but lower in priority than dealing with python bindings for GTK.
If you are doing options 2 and 3, you may want to change the default install prefix if you do end up making an installer (perhaps /opt/local/tigerportsstable and /opt/local/tigerportsunstable), that way people can easily have different versions side by side. Currently since all installation is from source this is not really relevant.
Option 2's biggest downside is that it doesn't get us all working on the same sources. On the plus side, you don't have to deal with things like a gcc update unless you want to. It also has the downside that yt-dlp will continue to necessitate updates of itself and its dependents which this approach will break down at addressing within five years or less.

Option 1: I think it is underestimated how much stuff was broken for PowerPC Tiger throughout Macports history. Before I read this forum thread in its entirety, I made a PR on your repository to patch the ld64-97 linker. Without that patched version, no version of mpv or the gstreamer1-gst-plugins ports have ever built from macports, as far as I can tell. PowerPC ports at least has mpv-legacy working on Tiger, minus some variants, and has the current gstreamer1 plugins.

I applaud the effort you are putting in to help keep Tiger useful for building software. I really hope you hew as close to the PPCPorts project as you are comfortable with so that duplication of effort can be minimized and more stuff can be fixed.

 

[alex_free]

Just catching up with this now. 3 is by far the best option, you could likely even pull my binaries from powerbookg4e.pagekite.me and save yourself some build time - though if you want to do clean builds there is an argument for that. I rarely deactivate everything before building, although that is best practice, because it takes hours on my hardware. If you have hardware you could automate as a buildbot, that would be amazing.
Option 3 also gets us all working on the same sources, especially if you start from the PPCports base that works on tiger: https://github.com/macos-powerpc/ppcports-base/tree/tiger_upd you could probably cherry-pick the commit restoring 10.4 support and use that to get the modern PowerPC Ports base working on Tiger. This is the best long term solution, because the more people who get fixes for Tiger into PowerPC ports, the better it will be. I could certainly use the help - PowerPC ports for Tiger is in better shape than I think Macports ever was at the moment, but I do struggle to keep up with breakages so I would really appreciate other people pitching in.
Keep in mind @barracuda156 has been very kind about letting Tiger have fallbacks where needed - this may end up being needed for glib2 and gobject-introspection because python-gobject3 bindings do not work with the modern versions (later than 2.79 for Glib2) on Tiger. I still think fixing the software is better than a fallback in that case, but I haven't found a fix yet.

If you also want to pursue option 2, it may be worth pulling PowerPC Ports fixes from here: https://github.com/macos-powerpc/powerpc-ports/releases/tag/2026.04 instead of the most recent PowerPC ports commit.
There have been some changes since that point which may be problematic to integrate into your project.
1. The breaking of python bindings for GTK happened after that point, with the update of glib2 and gobject-introspection.
2. Portgroups had some changes, which cause different assumptions than the base made in early 2025. Also, the cmake Portgroup brought in an rpath related argument which broke at least one port which I fixed, but it may have broken others I am unaware of.
3. We switched to gcc16, which seems to be working pretty well. It takes longer to build things than gcc14, and takes longer to build. Theoretically it is optimizing code better to make up for this. There are tradeoffs to be considered. Also, there are a couple of issues I brute forced through without checking with upstream in fixing the build. Checking with upstream is on my agenda but lower in priority than dealing with python bindings for GTK.
If you are doing options 2 and 3, you may want to change the default install prefix if you do end up making an installer (perhaps /opt/local/tigerportsstable and /opt/local/tigerportsunstable), that way people can easily have different versions side by side. Currently since all installation is from source this is not really relevant.
Option 2's biggest downside is that it doesn't get us all working on the same sources. On the plus side, you don't have to deal with things like a gcc update unless you want to. It also has the downside that yt-dlp will continue to necessitate updates of itself and its dependents which this approach will break down at addressing within five years or less.

Option 1: I think it is underestimated how much stuff was broken for PowerPC Tiger throughout Macports history. Before I read this forum thread in its entirety, I made a PR on your repository to patch the ld64-97 linker. Without that patched version, no version of mpv or the gstreamer1-gst-plugins ports have ever built from macports, as far as I can tell. PowerPC ports at least has mpv-legacy working on Tiger, minus some variants, and has the current gstreamer1 plugins.

I applaud the effort you are putting in to help keep Tiger useful for building software. I really hope you hew as close to the PPCPorts project as you are comfortable with so that duplication of effort can be minimized and more stuff can be fixed.

First of all, thanks for the input! I'm definitely set on option 2 or 3.
I am 100% on board with everyone working on the same upstream (PPCPorts). I'm just trying to take a conservative approach at the moment I guess. Either way, it only makes sense to start submitting my fixes to PPCPorts. I really, really want to ensure that at any given time binaries are available for key things like GCC.

The prefix indeed would be the way to do it as well. I will keep you updated on what ends up happening.

If I pull from the latest PPCPorts, I would get GCC16, But I see, port group changes might make that tricky, could you elaborate a bit more on that? Thanks for saving me some headache.

 

[Forest Expertise]

First of all, thanks for the input! I'm definitely set on option 2 or 3.
I am 100% on board with everyone working on the same upstream (PPCPorts). I'm just trying to take a conservative approach at the moment I guess. Either way, it only makes sense to start submitting my fixes to PPCPorts. I really, really want to ensure that at any given time binaries are available for key things like GCC.

The prefix indeed would be the way to do it as well. I will keep you updated on what ends up happening.

If I pull from the latest PPCPorts, I would get GCC16, But I see, port group changes might make that tricky, could you elaborate a bit more on that? Thanks for saving me some headache.

Port groups changes aren't relevant to gcc, but may be relevant to anything that builds with cmake: https://github.com/macos-powerpc/powerpc-ports/commit/cd34263c4179b6f439ab90fd99d2c360911b08c8
That commit adds an rpath related thing to ports that use the Cmake portgroup and broke at least one port that I fixed here: https://github.com/macos-powerpc/powerpc-ports/pull/170/files
It may have broken other ports as well (many use cmake), though the fix is trivial and should be the same as in that commit.
If it would be helpful, I can paste my most commonly used fixes here.
A binary is available for gcc16 through powerbookg4e.pagekite.me . That could save you a week of compiling if you go that route and stay in /opt/local. For other prefixes I believe you have to build in that prefix, but I wish I were wrong. On the plus side, it means you could keep your current work untouched presuming a big enough hard drive or SSD. On the minus side, it means you will be starting from scratch. Of course, you would basically be starting from scratch anyway since current gcc14 is 14.3 as opposed to 14.1 (or maybe 14.2 I can't remember) which was the version Macports had in January 2025. And gcc16 is gcc 16.1, which also would basically be a start from scratch, and takes even longer to build than gcc14.
Please keep me updated, I am happy to help if I have a good picture of what the goal is and which of my fixes would be useful.

 

[barracuda156]

@Forest Expertise A quick note re gcc (I reply from mobile now): using gcc14 is still possible (and trivial to) on current PPCPorts. You still need to compile libgcc16, but gcc14 works on top of that.

 

[Forest Expertise]

@Forest Expertise A quick note re gcc (I reply from mobile now): using gcc14 is still possible (and trivial to) on current PPCPorts. You still need to compile libgcc16, but gcc14 works on top of that.

Good to note, though I have been using gcc16 on top of libgcc16 for a few weeks now without major issues. It just seems to compile slower than gcc14 did. But hopefully the additional optimizations make up for that. It's also erroring on incompatible-pointer-types a little more than gcc14 did, but turning those errors back into warnings is trivial.
I assume you just configure.compiler like you would to use macports-gcc-10

 

[barracuda156]

Good to note, though I have been using gcc16 on top of libgcc16 for a few weeks now without major issues.

It is recommended anyway.

It just seems to compile slower than gcc14 did.

Not in my experience, at least I did not make that observation, and I compile a lot. But can be system-specific or cpu-specific. I also did no format measurements to compare side-by-side.

 

[alex_free]

@barracuda156 v1.0.6 of tigerports-base is out. autoclean is back to no for default, and it pulls down port index from the server rather then having to regenerate it on the tiger machine itself.

Port tree work is still on-going and not out yet.

Ton of binaries will be uploaded soon (especially if this intel cross build setup works out as well as I'm imagining).

Having some weird issues downloading from the garden for Xcode 2.5 and 10.4.11 combo updates using safari 2.0 (OTB version from 10.4.10 installer), so threw them up on the site.

Thankyou all for the support so far, still early days.

 

[barracuda156]

Somehow I absolutely missed that this was in Intel subforum. My general comments hold, and some fixes that were made for ppc apply just as well for intel (not too many issues are arch-specific), however nearly nothing was probably tested on old i386, so I have no idea what works.

 

[alex_free]

Somehow I absolutely missed that this was in Intel subforum. My general comments hold, and some fixes that were made for ppc apply just as well for intel (not too many issues are arch-specific), however nearly nothing was probably tested on old i386, so I have no idea what works.

We are gonna find out!

 

[barracuda156]

We are gonna find out!

From my brief exposure to 10.6 on i386 using gcc and libstdc++, I recall several ports assume presence of x86 intrinsics that is not actually supported by cctools. Specifically, aom, libyuv, libsodium. I could not convince upstreams it is their bug, they think it’s user problem, and checking capabilities correctly is not something worth bothering with LOL

Those ports may need manual hacks. PowerPC foregoes this pain completely, since x86 simd does not exist.

 

[Dave1423]

if only there was a .pkg...

 

[alex_free]

if only there was a .pkg...

Indeed, I haven’t gotten around to/figured out how they make those

 

[Forest Expertise]

Indeed, I haven’t gotten around to/figured out how they make those

sudo port -v mdmg macports
Then you find the resulting dmg file and distribute it.
Macports is actually a port. You can open the portfile.
Unfortunately, I never got it to build against external curl when building this way on Tiger, but with your infrastructure that may be less of a concern.
Mdmg/dmg/mpkg/pkg code can be wonky on Tiger. Reverting to an earlier version may be necessary.
I made a PPCPorts installer for Tiger once and put it on this forum, but I don't recall anyone being interested.
People still have to be able to install Xcode and follow instructions even if you make a pkg. Installing from source is not raising the barrier to entry by much if at all.
You might take a look at this: https://github.com/macports/macports-ports/tree/master/sysutils/MacPorts
P.S.: Whatever you do, DO NOT sudo port install Macports, it will destroy your installation. Destroot or mdmg/dmg/mpkg/pkg only
I would also highly suggest having separate Intel and PowerPC installers, I would be surprised if building this universal worked.

 

[barracuda156]

You might take a look at this: https://github.com/macports/macports-ports/tree/master/sysutils/MacPorts
P.S.: Whatever you do, DO NOT sudo port install Macports

It is impossible, the port won’t allow to get installed.

 

[alex_free]

sudo port -v mdmg macports
Then you find the resulting dmg file and distribute it.
Macports is actually a port. You can open the portfile.
Unfortunately, I never got it to build against external curl when building this way on Tiger, but with your infrastructure that may be less of a concern.
Mdmg/dmg/mpkg/pkg code can be wonky on Tiger. Reverting to an earlier version may be necessary.
I made a PPCPorts installer for Tiger once and put it on this forum, but I don't recall anyone being interested.
People still have to be able to install Xcode and follow instructions even if you make a pkg. Installing from source is not raising the barrier to entry by much if at all.
You might take a look at this: https://github.com/macports/macports-ports/tree/master/sysutils/MacPorts
P.S.: Whatever you do, DO NOT sudo port install Macports, it will destroy your installation. Destroot or mdmg/dmg/mpkg/pkg only
I would also highly suggest having separate Intel and PowerPC installers, I would be surprised if building this universal worked.

Interesting. I’ll have to give it a shot. Your right though, it’s just typing ‘cd’, dragging in the extracted release, and copying a one liner from the website to get going from source.

Now that I think of it, I can’t even remember the last time they had 10.4 installers (wasn’t it source tarball only)?

Building with an external curl (with modern OpenSSL/cert enabled) is not a priority because it has the rsync fallback. I could also point it to http sources, but the infrastructure and their sync script kind expects RELEASE_URL to point to a git repo base tag as is.

I actually build the release tarballs and whatnot from high sierra, perhaps it would just work tm?

Figuring out this macports stuff was pretty crazy, thanks for solving one more mystery.

 

[Forest Expertise]

Interesting. I’ll have to give it a shot. Your right though, it’s just typing ‘cd’, dragging in the extracted release, and copying a one liner from the website to get going from source.

Now that I think of it, I can’t even remember the last time they had 10.4 installers (wasn’t it source tarball only)?

Building with an external curl (with modern OpenSSL/cert enabled) is not a priority because it has the rsync fallback. I could also point it to http sources, but the infrastructure and their sync script kind expects RELEASE_URL to point to a git repo base tag as is.

I actually build the release tarballs and whatnot from high sierra, perhaps it would just work tm?

Figuring out this macports stuff was pretty crazy, thanks for solving one more mystery.

They had an installer for 2.10.7 (https://github.com/macports/macports-base/releases?page=2#release-v2.10.7). I would recommend building on actual hardware to make an installer for the base.
If you want to get stuff working on G3s, you may have to build on a G3 (probably even for the installer). Keeping this as a G4/G5 project makes the most sense until someone actually has a G3 to do things on.
I'm happy to keep answering questions, I am just glad to see a revival of interest in ports on Tiger, because when I started with Macports in May 2025 it was a low point.

It is impossible, the port won’t allow to get installed.

That's good that got fixed, I just recalled reading that advice and it scared me. Must have been outdated.

 

[barracuda156]

That's good that got fixed, I just recalled reading that advice and it scared me. Must have been outdated.

It was never broken, it is intended. Message is informational. See: https://github.com/macos-powerpc/po...c3ae1b6e/sysutils/MacPorts/Portfile#L469-L480

 

[alex_free]

They had an installer for 2.10.7 (https://github.com/macports/macports-base/releases?page=2#release-v2.10.7). I would recommend building on actual hardware to make an installer for the base.
If you want to get stuff working on G3s, you may have to build on a G3 (probably even for the installer). Keeping this as a G4/G5 project makes the most sense until someone actually has a G3 to do things on.
I'm happy to keep answering questions, I am just glad to see a revival of interest in ports on Tiger, because when I started with Macports in May 2025 it was a low point.

That's good that got fixed, I just recalled reading that advice and it scared me. Must have been outdated.

unless a project is using altivec or vmx, I don’t know why it wouldn’t work on G3. Tiger doesn’t have cpu subtypes to the level that like leopard does either. My understanding is intel can build with up to optional G4 features by cross compiling (but of course this could be disabled). And you’d need a G5 for any VMX based optimized builds.

 

[barracuda156]

And you’d need a G5 for any VMX based optimized builds.

VMX is just AltiVec, AFAIK. G4 supports it.

 

[alex_free]

VMX is just AltiVec, AFAIK. G4 supports it.

IIRC VMX is IBM’s version of it that is not exactly compatible but more advanced. When I was doing ffmpeg I could never compile it with vmx optimizations because i never had a G5