Snow Leopard on Unsupported PowerPC Macs

[B S Magnet]

Then we should take care of 10.5.3 .5 and .6 kext sets/kernel instead of focusing using 10.5.8 set to replace in 10A96

Yes and no.

In several cases, the 10.5.8-updated and 10.5.8-optimized components are shown to be stable and functional with the 10A96 and 10A190 builds — which isn’t terribly surprising, given how each minor system update squashes bugs and unresolved issues found with earlier minor versions of the system base.

A good case example of a 10.5.8-optimized component which works very well with at least 10A96 (and most likely 10A190 as well) is QuickTime 7.7.0 for Leopard. It was released almost a month after Lion in August 2011: QT 7.7.0’s frameworks, in significant part, restored QuickLook function for 10A96 and improved video playback on systems lacking CoreImage support and Quartz Extreme software support (such as with the AGP-based GPU Macs).

That said, when 10.5.8 and 10.5.8-optimized content don’t resolve a system function issue with 10A96 or 10A190, then, yes, it may be worthwhile to look into components sourced from 10.5.3, 10.5.4, 10.5.5, and even 10.5.6. A good case situation for this exploration would be Finder functionality: in 10A96, there are some quirks which qualify as bugs, and in 10A190, those bugs are even more so, some of them outlined by Apple themselves (though a separate caveat with the latter being how 10A190 is where the first iteration of a Cocoa Finder débuted, and grabbing Finder-related components from Carbon-streamed Finders might not help here).

So yes, in situations which 10.5.8-sourced components may not work any better than what came bundled with 10A96 or 10A190, it may be worthwhile to look at intermediate Leopard updates. By the same token, it is also worthwhile to yield to the most stable components of Leopard for testing in 10A96 and 10A190, since there do remain enough aspects where refinement from Leopard-intended components do solve issues.

[As a footnote to this: I have run across several instances of components in 10.6.8 which share the identical version number (in Info.plist and version.plist) as what appear in 10.5.8, but with one key difference: the mach-o ppc binary code was stripped with no further work done. At the time of Snow Leopard’s public release, Apple stressed how it was an under-the-bonnet refinement over Leopard, which is true, but there were several elements which carried over, unchanged, from Leopard — minus the stripping of PPC code. I’m guessing that during production, there was a requirement of developers to strip away PPC code in the event they were running across it anyway — which could also help to explain why there remains some residual PPC code lingering in even 10.6.8, as those elements were probably never visited during production and development of Snow Leopard.]

 

[Macbookprodude]

So, if the above is correct, then 10.6.8 can be updated on PowerPC Snow Leopard - nice. Good we now have Snow Leopard as an alternative platform + Leopard Sorbert.

 

[pc297]

So, if the above is correct, then 10.6.8 can be updated on PowerPC Snow Leopard - nice. Good we now have Snow Leopard as an alternative platform + Leopard Sorbert.

Well, there is still the - big - issue of the Finder as mentioned by @B S Magnet as well as likely several ppc-only components and core services from 10A96 or 10A190 that we are stuck with for the time being. So it doesn't look like there can be a rather straightforward solution as in e.g. MLPostFactor for which merely the 32-bit kernel was needed (supporting x64 execution) to to execute 64-bit apps including the Finder, plus adding-in missing 32-bit kexts - which per se already took a while to come up with. This obviously can't be done with ppc SL.

So the key to success is to find 10.5.X and ppc 10.6.X components that work with the ones in 1096 and 10A190, and see which one is better. Would be nice to have the 10A190 Finder though. Or if someone at apple would be kind enough to release updated internal ppc SL components such as the Finder or even internal ppc SL builds ?

 

[B S Magnet]

So, if the above is correct, then 10.6.8 can be updated on PowerPC Snow Leopard - nice. Good we now have Snow Leopard as an alternative platform + Leopard Sorbert.

No. ?‍♀️

Well, there is still the - big - issue of the Finder as mentioned by @B S Magnet as well as likely several ppc-only components and core services from 10A96 or 10A190 that we are stuck with for the time being.

Unless the community are given source code for building Finder and other core components (don’t count on it), the latest version of the Developer Preview builds which will launch completely on PowerPC architecture is 10A190, which was released in between when the 10.5.5 and 10.5.6 updates were.

So it doesn't look like there can be a rather straightforward solution as in e.g. MLPostFactor for which merely the 32-bit kernel was needed (supporting x64 execution) to to execute 64-bit apps including the Finder, plus adding-in missing 32-bit kexts - which per se already took a while to come up with. This obviously can't be done with ppc SL.

Correct. And dealing with Intel-based code is a completely different creature insofar as this project goes that comparisons to MLPostFactor do not apply.

So the key to success is to find 10.5.X and ppc 10.6.X components that work with the ones in 1096 and 10A190, and see which one is better. Would be nice to have the 10A190 Finder though. Or if someone at apple would be kind enough to release updated internal ppc SL components such as the Finder or even internal ppc SL builds ?

My project interest is to establish the best stability in whichever builds reach the end of their testing.

As for Finder, I’d prefer a stable Finder which works. Between the Carbonized Finder in 10A96 and the very early, almost pre-alpha Cocoa Finder in 10A190, I presently feel more confident with using 10A96’s Finder. Even so, the 10A96 Finder still could use some work which might be beyond our ability to address (see above re: lack of source code). This could change in the future, but for now, these circumstances are liable to remain unchanged.

 

[pc297]

Has anyone any ideas about the missing icon text in icon view in the 10A190 Finder? Replacing the Finder with the 10.5.8 one or 10A96 one doesn't work - most likely as neither are partly written in Cocoa? @ChrisCharman do you know if the 10A190 Finder displays icon text correctly on the cube as well(as for 10A96)? Interestingly booting into 10A190 on Intel does not result in missing icon text

 

[pc297]

For everyone's information: trying to boot 10A190 on Intel and enabling file-sharing and subsequently rebooting into ppc does not seem to be working, no file sharing enabled and obviously the sharing prefpane still crashes

 

[B S Magnet]

Minor and not too exciting updates:

If you’ve been following the WikiPost closely, you might remember we were recently given an extension on the max cap of characters for the WikiPost, which helped us with being able to add new testing infor & other Q&A-related stuff.

Welp, we’re nearing the new cap already, which is kind of amazing and also a new bottleneck we’ll have to work within for now. I went ahead and trim-edited a lot of stuff to recover a little bit of room, and you may notice an increase in abbreviations and a liberal use of the ampersand. Due to recent static with m o d‌‍s, someone else will need to gently ask them for an extension for when the time comes when we can’t add anything further without a new extension.

I’ve also added to Table 4 a bunch of new (from 10.5.8) Frameworks which have been moved into place in 10A96. I’ve found, for the most part, more testing on those will be needed. But there were a couple of findings which, in moving those Frameworks into place, mended some of the previously failed kexts (such as for FireWire audio support, which means iSight FireWire audio recording works with the full complement of newer components all correctly in place).

One of the things I’m looking for, UI-wise, is where the label boxes in the File menu and contextual menus live (shown below are the carryover squares from Leopard, as used in 10A96 and probably 10A190 as well). The Snow Leopard 10.6.8 squares are physically smaller, and I’m trying to find those for the 10A96/10A190 UX. If you happen to know, let me know!

[EDIT to add: Contrary to what I experienced earlier in testing, Screen Sharing.app from 10.5.8 (v1.0.3), when brought over with its companion PrivateFramework, will work in Build 10A96 and probably Build 10A190 as well. The Build 10A96 Screen Sharing group is v1.0, yet this version is much more feature-rich than its Leopard-designed counterpart. The 10.6.0 version, v1.1, crashes on launch and is a non-starter. For those of you testing, which version you use is a matter of personal preference.]

[SECOND EDIT to add: Back in mid-June, I ran Geekbench 2 benchmarks on the test PowerBook which runs 10A96. At the time, the highest scores were repeatedly coming in at 978. Tonight, following all the moves of 10.5.8 Frameworks and other lower-level components to the test build, I noticed the response and turnaround time when logging out, then logging back in and reaching Finder, was perceptibly quicker than much earlier during the project. UI response isn’t something which Geekbench gauges, but it does measure stuff under the bonnet — stuff which stability improvements and updates (from 10.5.8) would probably help. So I did a “best of three” tonight. The lowest was 980, and the highest was 984. It’s a trivial improvement over six weeks ago, but otherwise not bad. As hardware bottlenecks go, I am running PC2-3200/288MHz SO-DIMMs, whereas OEM specs called for PC2-4200/333MHz. At some point, I’ll need to tend to that.]

 

[ChrisCharman]

Has anyone any ideas about the missing icon text in icon view in the 10A190 Finder? Replacing the Finder with the 10.5.8 one or 10A96 one doesn't work - most likely as neither are partly written in Cocoa? @ChrisCharman do you know if the 10A190 Finder displays icon text correctly on the cube as well(as for 10A96)? Interestingly booting into 10A190 on Intel does not result in missing icon text

Hi @pc297

Unfortunately I don’t have a cube to test my build on, however the only system i recall experiencing the issue with was the ‘supported’ PowerMac G5 - all systems that i own that are not Quartz Extreme supported do not have this issue. I do need to test my updated build on the G5 soon as i’ve mainly been using it on the iBook and PowerBook of late.

 

[ChrisCharman]

For everyone's information: trying to boot 10A190 on Intel and enabling file-sharing and subsequently rebooting into ppc does not seem to be working, no file sharing enabled and obviously the sharing prefpane still crashes

I have intermittent file sharing working on 10A190 - once it’s fully functional i’ll share the fix.

Have you already updated Cups?

 

[pc297]

I have intermittent file sharing working on 10A190 - once it’s fully functional i’ll share the fix.

Have you already updated Cups?

Great to hear! No, I'll give it a go, thanks for the tip!

 

[B S Magnet]

Minor update!

This update is mostly relating to optional command-level stuff, if that’s more your jam — specifically, the use of Macports on Snow Leopard for PowerPC.

As noted in the updated Table 5 of the WikiPost, it is fairly straightforward to compile and install the latest Macports for Snow Leopard on PowerPC. The problem beyond that, however, remains one of port unavailability.

Only a few ports, such as mpstats and neofetch, exist as “noarch” ports (i.e., ports with no dependency on or requirement for a specific architecture) for Darwin 10 (Snow Leopard). None, of course, exist for “ppc”, because following Apple’s commitment to produce Snow Leopard for Intel architecture only, third-party developers (including package distributors like Macports) made distributions available for compiling on Intel hardware (either as “i386” or “x86_64) only.

As described in Table 5, one workaround is to create .pkg installers of individual ports using a PPC Leopard Mac running its own Macports, followed by just launching those .pkg files in Finder to install instead of having to worry about building/compiling on your PowerPC running either Build 10A96 or 10A190. Certain foundational ports are needed to compile/build more specific things — such as the IRC client, irssi.

So what I’ve done is create a selection of these foundational .pkg installers you can use with SL-PPC to then build/compile your own stuff. I’ve definitely missed some of these, and I’m not yet sure whether all of these will attach over the next couple of posts (update: the max attachment size is 20MB). All of these pkg’d ports were made in Darwin 9 with Macports 2.7.1 (currently the latest version). This should be enough to help more savvy command-line folks to do more in the SL-PPC environment.

In this batch (each is <16MB) [version] (updated: 2021.10.13 in blue):

bash [5.1.8]
binutils [2.37]
cctools [949.0.1.1]
curl [7.78.0]
gettext [0.19.8.1.2]
glib2 [2.62.6] [2.62.6.2]
gnutls [3.6.16.1]
ld64 [3.0.3]
libffi [3.3.0.1] [3.4.2]
libgcrypt [1.9.3] [1.9.4]
libgpg-error [1.42]
libiconv [1.16.1]
libutf8proc [2.6.1]
lzip [1.2.2]
meson [0.58.1] [0.59.1.2]
ncurses [6.2.1]
ninja [1.10.2.1]
nmap [7.92]
openssl [1.1.1k] [1.1.1l.1]
pcre2 [10.37]
pkgconfig [0.29.2]
re2c [2.2]
rsync [3.2.3]
sqlite3 [3.36.0]
tcl [8.6.11]
wget [1.21.1.1] [1.21.2]
zsh [5.8.1]



Total attached: 27

 

[B S Magnet]

Minor update!

This update is mostly relating to optional command-level stuff, if that’s more your jam — specifically, the use of Macports on Snow Leopard for PowerPC.

As noted in the updated Table 5 of the WikiPost, it is fairly straightforward to compile and install the latest Macports for Snow Leopard on PowerPC. The problem beyond that, however, remains one of port unavailability.

Only a few ports, such as mpstats and neofetch, exist as “noarch” ports (i.e., ports with no dependency on or requirement for a specific architecture) for Darwin 10 (Snow Leopard). None, of course, exist for “ppc”, because following Apple’s commitment to produce Snow Leopard for Intel architecture only, third-party developers (including package distributors like Macports) made distributions available for compiling on Intel hardware (either as “i386” or “x86_64) only.

As described in Table 5, one workaround is to create .pkg installers of individual ports using a PPC Leopard Mac running its own Macports, followed by just launching those .pkg files in Finder to install instead of having to worry about building/compiling on your PowerPC running either Build 10A96 or 10A190. Certain foundational ports are needed to compile/build more specific things — such as the IRC client, irssi.

So what I’ve done is create a selection of these foundational .pkg installers you can use with SL-PPC to then build/compile your own stuff. I’ve definitely missed some of these, and I’m not yet sure whether all of these will attach over the next couple of posts (update: the max attachment size is 20MB). All of these pkg’d ports were made in Darwin 9 with Macports 2.7.1 (currently the latest version). This should be enough to help more savvy command-line folks to do more in the SL-PPC environment.

In this batch [version]:

ld64 [3.0]
libffi [3.3]
lzip [1.2.2]
ninja [1.10.2]
libutf8proc [2.6.1]
pkgconfig [0.29.2]
libgpg-error [1.42]
rsync [3.2.3]
re2c [2.2]
libgcrypt [1.93]
wget [1.21.1]
meson [0.58.1]
libiconv [1.16]
ncurses [6.2]
pcre2 [10.37]
sqlite3 [3.36.0]
bash [5.1.8]
cctools [949.0.1]
gnutls [3.6.16]
tcl [8.6.11]
binutils [2.37]
openssl [1.1.1k]
zsh [5.8]
gettext [0.19.8.1]
glib2 [2.62.6]
cmake [3.20.5]

Total attached: 26

And in this batch, each (16MB+ each) [version] is attached to a Google Drive link (updated: 2021.10.13 in blue):

clang-3.4 [3.4.2.15] [3.4.2.16]
db48 [4.8.28] [4.8.30.4]
db53 [5.3.28]
gcc7 [7.5.0.2]
git [2.32.0.1] [2.33.0.1]
llvm-3.4 [3.4.2.15] [3.4.2.16]
perl-5.32 [5.32.1]
python39 [3.9.6] [3.9.7]


Total linked: 8

EDIT to add: If someone needs a particular port they want to install on their SL-PPC test Mac and are having trouble with running a “sudo port pkg [portname]” on that port, let me know and I’ll try to put together a .pkg and post it either here (as a link) or in the previous post (as an attachment).

 

[kencu]

This post and the following will explain how to install a properly working MacPorts on 10A190 (the other older PPC SnowLeopard version has not been tested by me, although I did use the Xcode installation from it as that is the only one I know of that is available).

This post is overly long so as to be extremely detailed for those inexperienced in some of the finer details of MacPorts. In practice, this process takes about 5 minutes to accomplish, not including the time it takes MacPorts to first parse the Portfiles (about 60 minutes or so).

To install MacPorts on PPC SnowLeopard requires overriding some of MacPorts' default assumptions that are coded into the source for MacPorts base, PortGroups, and some Portfiles, but is possible with "some assembly required".

In addition, to install software that requires newer compilers required some tweaking to gcc7 to enable it to understand the differences between the System on 10A190 and SnowLeopard 10.6.8, which is what gcc7 is built to build and run against. I believe I have spotted most, hopefully all, of these hiccups, but no promises. The modifications I made do work for me to install a number of ports. I have not as yet tried to work these issues out on gcc-4.5 through gcc-6.0. I would imagine they might be similar, but I have only tweaked gcc7.

MacPorts currently is set up to use gcc11 on SnowLeopard; unfortunately gcc11 has internal compiler errors during the build (ICEs) that I have so far not been able to repair. gcc7 was the default gcc/libgcc for SnowLeopard until recently, and still is the default gcc/libgcc for Tiger and Leopard (PPC and Intel) so I had to roll back the default gcc/libgcc that was used on MacPorts to gcc7 for PPC SnowLeopard, at least until that can be sorted out, if it ever will be.

I'll start with the ports I have installed already (138) and mention that 12 of those needed some kind of special tweak for PPC SnowLeopard, to give you an idea of the hands-on that might be required.

I will try to walk you through how to set this up, which requires a few minor tweaks.

Here are the installed ports I have at the moment:

Spoiler

$ port -v installed
The following ports are currently installed:
autoconf @2.71_1 (active) requested_variants='' platform='darwin 10' archs='noarch' date='2021-08-24T09:06:24-0700'
automake @1.16.3_0 (active) requested_variants='' platform='darwin 10' archs='noarch' date='2021-08-24T09:06:52-0700'
bzip2 @1.0.8_0 (active) requested_variants='' platform='darwin 10' archs='ppc' date='2021-08-22T21:44:04-0700'
cctools @949.0.1_1 (active) requested_variants='' platform='darwin 10' archs='ppc' date='2021-08-22T21:42:09-0700'
cmake @3.20.5_2 (active) requested_variants='' platform='darwin 10' archs='ppc' date='2021-08-31T22:00:59-0700'
coreutils @8.32_0 (active) requested_variants='' platform='darwin 10' archs='ppc' date='2021-08-24T10:02:23-0700'
curl @7.78.0_0+ssl (active) requested_variants='' platform='darwin 10' archs='ppc' date='2021-08-24T09:49:03-0700'
curl-ca-bundle @7.78.0_0 (active) requested_variants='' platform='darwin 10' archs='noarch' date='2021-08-24T08:59:56-0700'
db48 @4.8.30_4 (active) requested_variants='' platform='darwin 10' archs='ppc' date='2021-08-23T11:31:10-0700'
docbook-xml-4.5 @5.0_1 (active) requested_variants='' platform='darwin 10' archs='noarch' date='2021-08-28T00:42:08-0700'
docbook-xsl-nons @1.79.2_0 (active) requested_variants='' platform='darwin 10' archs='noarch' date='2021-08-28T00:43:40-0700'
expat @2.4.1_0 (active) requested_variants='' platform='darwin 10' archs='ppc' date='2021-08-23T11:33:02-0700'
expect @5.45.4_1 (active) requested_variants='' platform='darwin 10' archs='ppc' date='2021-08-31T22:19:18-0700'
fop @1.1_1 (active) requested_variants='' platform='darwin 10' archs='noarch' date='2021-08-28T00:47:08-0700'
gcc7 @7.5.0_2 (active) requested_variants='' platform='darwin 10' archs='ppc' date='2021-08-31T17:40:03-0700'
gcc7-bootstrap @7.5.0_0 (active) requested_variants='' platform='darwin 10' archs='ppc' date='2021-09-01T06:30:47-0700'
gcc_select @0.1_9 (active) requested_variants='' platform='darwin 10' archs='noarch' date='2021-08-23T16:54:23-0700'
gdbm @1.20_1 (active) requested_variants='' platform='darwin 10' archs='ppc' date='2021-08-23T12:24:21-0700'
gettext @0.19.8.1_2 (active) requested_variants='' platform='darwin 10' archs='ppc' date='2021-08-22T21:29:04-0700'
git @2.33.0_1+credential_osxkeychain+diff_highlight+doc+pcre+perl5_28 (active) requested_variants='' platform='darwin 10' archs='ppc' date='2021-08-24T20:02:51-0700'
gmp @6.2.1_0 (active) requested_variants='' platform='darwin 10' archs='ppc' date='2021-08-24T09:55:01-0700'
gnutar @1.34_0 (active) requested_variants='' platform='darwin 10' archs='ppc' date='2021-08-24T19:21:41-0700'
gperf @3.1_0 (active) requested_variants='' platform='darwin 10' archs='ppc' date='2021-08-22T20:47:53-0700'
help2man @1.48.4_0 (active) requested_variants='' platform='darwin 10' archs='ppc' date='2021-08-24T09:23:35-0700'
icu @67.1_4 (active) requested_variants='' platform='darwin 10' archs='ppc' date='2021-08-31T20:54:27-0700'
isl @0.22.1_0 (active) requested_variants='' platform='darwin 10' archs='ppc' date='2021-08-24T21:42:46-0700'
kerberos5 @1.19.2_0 (active) requested_variants='' platform='darwin 10' archs='ppc' date='2021-08-24T17:42:12-0700'
ld64 @3_3+ld64_127 (active) requested_variants='' platform='darwin 10' archs='ppc' date='2021-08-23T15:04:32-0700'
ld64-127 @127.2_14+llvm34 (active) requested_variants='' platform='darwin 10' archs='ppc' date='2021-08-23T20:19:40-0700'
legacy-support @1.0.3_0 (active) requested_variants='' platform='darwin 10' archs='ppc' date='2021-08-27T08:04:37-0700'
libarchive @3.5.2_0 (active) requested_variants='' platform='darwin 10' archs='ppc' date='2021-08-28T18:18:02-0700'
libcomerr @1.45.6_0 (active) requested_variants='' platform='darwin 10' archs='ppc' date='2021-08-24T10:03:30-0700'
libedit @20210216-3.1_0 (active) requested_variants='' platform='darwin 10' archs='ppc' date='2021-08-23T11:34:13-0700'
libffi @3.3_1 (active) requested_variants='' platform='darwin 10' archs='ppc' date='2021-08-23T11:34:58-0700'
libgcc @5.0_0 (active) requested_variants='' platform='darwin 10' archs='ppc' date='2021-08-26T17:20:20-0700'
libgcc7 @7.5.0_1 (active) requested_variants='' platform='darwin 10' archs='ppc' date='2021-08-26T17:19:54-0700'
libiconv @1.16_1 (active) requested_variants='' platform='darwin 10' archs='ppc' date='2021-08-22T20:53:42-0700'
libidn @1.38_0 (active) requested_variants='' platform='darwin 10' archs='ppc' date='2021-08-24T17:53:06-0700'
libidn2 @2.3.2_0 (active) requested_variants='' platform='darwin 10' archs='ppc' date='2021-08-24T09:37:55-0700'
libmacho @949.0.1_0 requested_variants='' platform='darwin 10' archs='ppc' date='2021-08-28T13:34:54-0700'
libmacho-headers @949.0.1_0 (active) requested_variants='' platform='darwin 10' archs='noarch' date='2021-08-23T15:01:52-0700'
libmpc @1.2.1_0 (active) requested_variants='' platform='darwin 10' archs='ppc' date='2021-08-24T21:51:39-0700'
libpsl @0.21.1-20210726_2 (active) requested_variants='' platform='darwin 10' archs='ppc' date='2021-08-24T09:38:59-0700'
libtool @2.4.6_11 (active) requested_variants='' platform='darwin 10' archs='ppc' date='2021-08-24T09:07:45-0700'
libunistring @0.9.10_0 (active) requested_variants='' platform='darwin 10' archs='ppc' date='2021-08-24T09:36:27-0700'
libunwind @5.0.1_0 requested_variants='' platform='darwin 10' archs='ppc' date='2021-08-28T13:38:14-0700'
libunwind-headers @5.0.1_0 requested_variants='' platform='darwin 10' archs='noarch' date='2021-08-22T21:33:18-0700'
libuv @1.30.0_0 (active) requested_variants='' platform='darwin 10' archs='ppc' date='2021-08-28T18:20:47-0700'
libxml2 @2.9.12_1 (active) requested_variants='' platform='darwin 10' archs='ppc' date='2021-08-28T18:09:33-0700'
llvm-3.4 @3.4.2_14 (active) requested_variants='' platform='darwin 10' archs='ppc' date='2021-08-23T14:54:52-0700'
llvm_select @2_0 (active) requested_variants='' platform='darwin 10' archs='noarch' date='2021-08-23T14:00:06-0700'
lmdb @0.9.29_0 (active) requested_variants='' platform='darwin 10' archs='ppc' date='2021-08-24T10:03:44-0700'
lz4 @1.9.3_1 (active) requested_variants='' platform='darwin 10' archs='ppc' date='2021-08-24T09:39:21-0700'
lzo2 @2.10_0 (active) requested_variants='' platform='darwin 10' archs='ppc' date='2021-08-28T18:12:17-0700'
m4 @1.4.19_1 (active) requested_variants='' platform='darwin 10' archs='ppc' date='2021-08-24T09:06:07-0700'
mpfr @4.1.0_0 (active) requested_variants='' platform='darwin 10' archs='ppc' date='2021-08-24T21:50:25-0700'
ncurses @6.2_1 (active) requested_variants='' platform='darwin 10' archs='ppc' date='2021-08-22T20:45:57-0700'
openssl @1.1.1k_0 (active) requested_variants='' platform='darwin 10' archs='ppc' date='2021-08-23T13:16:30-0700'
p5.28-authen-sasl @2.160.0_0 (active) requested_variants='' platform='darwin 10' archs='noarch' date='2021-08-24T17:43:20-0700'
p5.28-b-cow @0.4.0_0 (active) requested_variants='' platform='darwin 10' archs='ppc' date='2021-08-24T17:43:38-0700'
p5.28-capture-tiny @0.480.0_0 (active) requested_variants='' platform='darwin 10' archs='noarch' date='2021-08-24T17:45:45-0700'
p5.28-cgi @4.530.0_0 (active) requested_variants='' platform='darwin 10' archs='noarch' date='2021-08-24T17:48:35-0700'
p5.28-clone @0.450.0_0 (active) requested_variants='' platform='darwin 10' archs='ppc' date='2021-08-24T17:43:46-0700'
p5.28-cpan-meta @2.150.10_0 (active) requested_variants='' platform='darwin 10' archs='noarch' date='2021-08-24T17:49:50-0700'
p5.28-cpan-meta-requirements @2.140.0_0 (active) requested_variants='' platform='darwin 10' archs='noarch' date='2021-08-24T17:46:07-0700'
p5.28-cpan-meta-yaml @0.18.0_0 (active) requested_variants='' platform='darwin 10' archs='noarch' date='2021-08-24T17:49:28-0700'
p5.28-devel-checkbin @0.40.0_0 (active) requested_variants='' platform='darwin 10' archs='noarch' date='2021-08-24T17:46:38-0700'
p5.28-digest-hmac @1.40.0_0 (active) requested_variants='' platform='darwin 10' archs='noarch' date='2021-08-24T09:49:30-0700'
p5.28-digest-sha1 @2.130.0_4 (active) requested_variants='' platform='darwin 10' archs='ppc' date='2021-08-24T09:49:19-0700'
p5.28-encode @3.120.0_0 (active) requested_variants='' platform='darwin 10' archs='ppc' date='2021-08-24T17:44:56-0700'
p5.28-encode-locale @1.50.0_0 (active) requested_variants='' platform='darwin 10' archs='noarch' date='2021-08-24T17:45:05-0700'
p5.28-error @0.170.290_0 (active) requested_variants='' platform='darwin 10' archs='noarch' date='2021-08-24T17:48:43-0700'
p5.28-extutils-makemaker @7.620.0_0 (active) requested_variants='' platform='darwin 10' archs='noarch' date='2021-08-24T17:46:30-0700'
p5.28-extutils-manifest @1.730.0_0 (active) requested_variants='' platform='darwin 10' archs='noarch' date='2021-08-24T17:46:16-0700'
p5.28-gssapi @0.280.0_3 (active) requested_variants='' platform='darwin 10' archs='ppc' date='2021-08-24T17:43:10-0700'
p5.28-html-parser @3.760.0_0 (active) requested_variants='' platform='darwin 10' archs='ppc' date='2021-08-24T17:47:53-0700'
p5.28-html-tagset @3.200.0_4 (active) requested_variants='' platform='darwin 10' archs='noarch' date='2021-08-24T17:43:28-0700'
p5.28-http-date @6.50.0_0 (active) requested_variants='' platform='darwin 10' archs='noarch' date='2021-08-24T17:45:29-0700'
p5.28-http-message @6.330.0_0 (active) requested_variants='' platform='darwin 10' archs='noarch' date='2021-08-24T17:47:40-0700'
p5.28-inc-latest @0.500.0_0 (active) requested_variants='' platform='darwin 10' archs='noarch' date='2021-08-24T17:49:58-0700'
p5.28-io @1.450.0_0 (active) requested_variants='' platform='darwin 10' archs='ppc' date='2021-08-24T17:48:54-0700'
p5.28-io-html @1.4.0_0 (active) requested_variants='' platform='darwin 10' archs='noarch' date='2021-08-24T17:45:37-0700'
p5.28-io-socket-inet6 @2.720.0_0 (active) requested_variants='' platform='darwin 10' archs='noarch' date='2021-08-24T17:49:19-0700'
p5.28-io-socket-ip @0.410.0_0 (active) requested_variants='' platform='darwin 10' archs='noarch' date='2021-08-24T17:51:14-0700'
p5.28-io-socket-ssl @2.72.0_0 (active) requested_variants='' platform='darwin 10' archs='noarch' date='2021-08-24T17:54:30-0700'
p5.28-lwp-mediatypes @6.40.0_0 (active) requested_variants='' platform='darwin 10' archs='noarch' date='2021-08-24T17:47:13-0700'
p5.28-module-build @0.423.100_0 (active) requested_variants='' platform='darwin 10' archs='noarch' date='2021-08-24T17:50:55-0700'
p5.28-module-metadata @1.0.37_0 (active) requested_variants='' platform='darwin 10' archs='noarch' date='2021-08-24T17:50:08-0700'
p5.28-mozilla-ca @20200520_0 (active) requested_variants='' platform='darwin 10' archs='noarch' date='2021-08-24T17:51:21-0700'
p5.28-net-libidn @0.120.0_5 (active) requested_variants='' platform='darwin 10' archs='ppc' date='2021-08-24T17:53:18-0700'
p5.28-net-smtp-ssl @1.40.0_0 (active) requested_variants='' platform='darwin 10' archs='noarch' date='2021-08-24T17:54:38-0700'
p5.28-net-ssleay @1.900.0_0 (active) requested_variants='' platform='darwin 10' archs='ppc' date='2021-08-24T17:54:20-0700'
p5.28-perl-ostype @1.10.0_0 (active) requested_variants='' platform='darwin 10' archs='noarch' date='2021-08-24T17:50:15-0700'
p5.28-pod-escapes @1.70.0_0 (active) requested_variants='' platform='darwin 10' archs='noarch' date='2021-08-24T17:50:23-0700'
p5.28-pod-simple @3.430.0_0 (active) requested_variants='' platform='darwin 10' archs='noarch' date='2021-08-24T17:50:33-0700'
p5.28-podlators @4.140.0_0 (active) requested_variants='' platform='darwin 10' archs='noarch' date='2021-08-24T17:50:44-0700'
p5.28-scalar-list-utils @1.560.0_0 (active) requested_variants='' platform='darwin 10' archs='ppc' date='2021-08-24T17:45:58-0700'
p5.28-socket @2.32.0_0 (active) requested_variants='' platform='darwin 10' archs='ppc' date='2021-08-24T17:51:06-0700'
p5.28-socket6 @0.290.0_0 (active) requested_variants='' platform='darwin 10' archs='ppc' date='2021-08-24T17:49:11-0700'
p5.28-sub-name @0.260.0_0 (active) requested_variants='' platform='darwin 10' archs='ppc' date='2021-08-24T17:46:48-0700'
p5.28-sub-uplevel @0.280.0_0 (active) requested_variants='' platform='darwin 10' archs='noarch' date='2021-08-24T17:48:18-0700'
p5.28-term-readkey @2.380.0_0 (active) requested_variants='' platform='darwin 10' archs='ppc' date='2021-08-24T17:54:51-0700'
p5.28-test-deep @1.130.0_0 (active) requested_variants='' platform='darwin 10' archs='noarch' date='2021-08-24T17:48:02-0700'
p5.28-test-exception @0.430.0_0 (active) requested_variants='' platform='darwin 10' archs='noarch' date='2021-08-24T17:53:26-0700'
p5.28-test-fatal @0.16.0_0 (active) requested_variants='' platform='darwin 10' archs='noarch' date='2021-08-24T17:47:04-0700'
p5.28-test-needs @0.2.9_0 (active) requested_variants='' platform='darwin 10' archs='noarch' date='2021-08-24T17:47:20-0700'
p5.28-test-nowarnings @1.60.0_0 (active) requested_variants='' platform='darwin 10' archs='noarch' date='2021-08-24T17:48:10-0700'
p5.28-test-warn @0.360.0_0 (active) requested_variants='' platform='darwin 10' archs='noarch' date='2021-08-24T17:48:26-0700'
p5.28-time-local @1.300.0_0 (active) requested_variants='' platform='darwin 10' archs='noarch' date='2021-08-24T17:45:13-0700'
p5.28-timedate @2.330.0_0 (active) requested_variants='' platform='darwin 10' archs='noarch' date='2021-08-24T17:45:21-0700'
p5.28-try-tiny @0.300.0_0 (active) requested_variants='' platform='darwin 10' archs='noarch' date='2021-08-24T17:46:56-0700'
p5.28-uri @5.90.0_0 (active) requested_variants='' platform='darwin 10' archs='noarch' date='2021-08-24T17:47:30-0700'
p5.28-version @0.992.900_0 (active) requested_variants='' platform='darwin 10' archs='ppc' date='2021-08-24T17:49:40-0700'
p5.30-locale-gettext @1.70.0_0 (active) requested_variants='' platform='darwin 10' archs='ppc' date='2021-08-24T09:23:26-0700'
pcre @8.45_0 (active) requested_variants='' platform='darwin 10' archs='ppc' date='2021-08-27T08:08:36-0700'
pcre2 @10.37_0 (active) requested_variants='' platform='darwin 10' archs='ppc' date='2021-08-24T17:59:46-0700'
perl5 @5.28.3_0+perl5_28 (active) requested_variants='' platform='darwin 10' archs='noarch' date='2021-08-23T13:00:38-0700'
perl5.28 @5.28.3_4 (active) requested_variants='' platform='darwin 10' archs='ppc' date='2021-08-23T12:43:22-0700'
perl5.30 @5.30.3_3 (active) requested_variants='' platform='darwin 10' archs='ppc' date='2021-08-24T09:22:52-0700'
pkgconfig @0.29.2_0 (active) requested_variants='' platform='darwin 10' archs='ppc' date='2021-08-23T13:20:14-0700'
popt @1.18_1 (active) requested_variants='' platform='darwin 10' archs='ppc' date='2021-08-24T18:00:27-0700'
python2_select @0.0_3 (active) requested_variants='' platform='darwin 10' archs='noarch' date='2021-08-23T13:20:18-0700'
python3_select @0.0_2 (active) requested_variants='' platform='darwin 10' archs='noarch' date='2021-08-23T18:44:20-0700'
python27 @2.7.18_2 (active) requested_variants='' platform='darwin 10' archs='ppc' date='2021-08-23T13:37:05-0700'
python39 @3.9.6_0 (active) requested_variants='' platform='darwin 10' archs='ppc' date='2021-08-24T00:22:00-0700'
python_select @0.3_9 (active) requested_variants='' platform='darwin 10' archs='noarch' date='2021-08-23T13:20:20-0700'
readline @8.1.000_0 (active) requested_variants='' platform='darwin 10' archs='ppc' date='2021-08-23T12:23:12-0700'
rsync @3.2.3_0 (active) requested_variants='' platform='darwin 10' archs='ppc' date='2021-08-24T19:14:44-0700'
sqlite3 @3.36.0_0 (active) requested_variants='' platform='darwin 10' archs='ppc' date='2021-08-23T13:25:17-0700'
tcl @8.6.11_0+corefoundation+threads (active) requested_variants='' platform='darwin 10' archs='ppc' date='2021-08-31T22:18:20-0700'
texinfo @6.8_0 (active) requested_variants='' platform='darwin 10' archs='ppc' date='2021-08-24T09:26:48-0700'
the_silver_searcher @2.2.0_0 (active) requested_variants='' platform='darwin 10' archs='ppc' date='2021-08-27T08:11:03-0700'
xmlcatmgr @2.2_1 (active) requested_variants='' platform='darwin 10' archs='ppc' date='2021-08-28T00:42:02-0700'
xxhashlib @0.8.0_0 (active) requested_variants='' platform='darwin 10' archs='ppc' date='2021-08-24T19:12:48-0700'
xz @5.2.5_0 (active) requested_variants='' platform='darwin 10' archs='ppc' date='2021-08-22T21:33:06-0700'
zlib @1.2.11_0 (active) requested_variants='' platform='darwin 10' archs='ppc' date='2021-08-23T11:35:18-0700'
zstd @1.5.0_0 (active) requested_variants='' platform='darwin 10' archs='ppc' date='2021-08-24T09:44:31-0700'

To begin, you install MacPorts from source as usual, into any location, but I used the default /opt/local.

Then, before you do anything else such as try to run "port selfupdate", you must change the default configuration that MacPorts will use, by editing /opt/local/etc/macports/macports.conf.

1. You are going to tell MacPorts that you want to use a build architecture of PPC (instead of the default, which is Intel i386 or x86_64 on SnowLeopard). To do this, you set build_arch to ppc.
2. You are going to tell MacPorts that you do not want to ever try to build a universal binary (because there is no ppc64 in the PPCSL system, and you don't want to try to start building cross-architecture ppc/i386 binaries on this setup, already fragile, and besides MacPorts is unable to build cross arch ppc/i386 binaries using newer compilers such as gcc7 anyway, so it will just fail badly. To do this, you set universal_archs to nothing.
3. You are going to tell MacPorts you do not want to download any prebuilt binaries from the MacPorts buildbot, as they will never be built for PPC SnowLeopard on that site anyway, and anything you do download will be just wrong. You need to build everything from source code. (Someday there could be a buildbot set up by someone like me to generate and provide prebuilt PPC SnowLeopard binaries that could be downloaded and used just like the ones on MacPorts are already, but that is not available today and I want to set things up so you can get this going on your own and not rely on that). To do this, you set buildfromsource to always.
4. You are going to tell MacPorts to use libstdc++ as the default c++ standard library. Currently the default for Intel SnowLeopard is to use libc++, and libc++ will just not work on PPC at present (working on it ... ). To do this, you set cxx_stdlib to libstdc++

To make these changes, we add these lines to the top of /opt/local/etc/macports/macports.conf:

build_arch              ppc
universal_archs
buildfromsource         always
cxx_stdlib              libstdc++

Now, just to be 100% certain we never try to download any prebuilt binaries from the MacPorts site (which is something that someone might accidentally try to do using a command line switch or by removing the buildfromsource always line), we are going to tell MacPorts that the buildbot binaries do not exist at all any more. To do that, we edit the file /opt/local/etc/macports/archive_sites.conf, and we follow the instructions on the last three lines that tell us how to disable the archive_site, by changing this:

$ diff -u archive_sites.conf.default archive_sites.conf
--- archive_sites.conf.default    2021-08-22 14:16:52.000000000 -0700
+++ archive_sites.conf    2021-08-22 14:21:54.000000000 -0700
@@ -52,4 +52,4 @@

# To disable the default archive source, uncomment the following dummy
# entry; it will shadow the one from the ports tree.
-#name                    macports_archives
+name                    macports_archives

or for anyone who does not yet follow what a diff file shows, we change the last three lines to this:

# To disable the default archive source, uncomment the following dummy
# entry; it will shadow the one from the ports tree.
name                    macports_archives

After that, things are close to working for simpler ports (the ones that use the built in compilers in /usr/), but there was one more hiccup to fix before the downloads would work correctly. The sandboxing code is slightly different between Leopard and SnowLeopard, and on PPC SnowLeopard, we have to use the older Leopard version. I did that like this:

$ diff -u /opt/local/libexec/macports/lib/port1.0/portsandbox.tcl.orig /opt/local/libexec/macports/lib/port1.0/portsandbox.tcl
--- /opt/local/libexec/macports/lib/port1.0/portsandbox.tcl.orig    2021-09-01 15:47:07.000000000 -0700
+++ /opt/local/libexec/macports/lib/port1.0/portsandbox.tcl    2021-08-29 19:33:28.000000000 -0700
@@ -121,7 +121,7 @@
     foreach dir $allow_dirs {
         foreach perm $perms {
             append portsandbox_profile " (allow $perm ("
-            if {${os.major} > 9} {
+            if {${os.major} > 10} {
                 append portsandbox_profile "subpath \"${dir}\"))"
             } else {
                 append portsandbox_profile "regex #\"^${dir}/\"))"

at that point, MacPorts began working correctly. You THEN run "sudo port -v sync" and MacPorts will update it's local copy of all the Portfiles, and then iterate through each one, generating an index of what is happening in the Portfiles. If you run "sudo port -v sync" before you make the architecture changes above, then the PortFiles can be parsed incorrectly (following the default code paths for Intel on SnowLeopard instead of code paths for PPC). So it is best if you generate this Index AFTER you have updated your macports.conf.

That first iteration through all the PortFiles takes a long time. There are over 25,000 of them to parse and index. Usually when you install MacPorts you download a premade index, but there is no premade index for PPC on SnowLeopard because there is no system at MacPorts buildbot base that generates this. So you have to make it yourself.

At this point you will hopefully be able to install simple ports, building natively for darwin10 ppc. I will follow this post with the next set of instructions, that will cover how to override the default libgcc to make it libgcc7 instead of libgcc11, and how to override the compiler choices MacPorts uses, so as to never use clang on PPC SnowLeopard (clang and llvm just do not work on Darwin PPC at present, so there is no point trying to use them for anything much at all).

The next set of instructions will follow, but you can do the above if you wish. Some ports will not build yet until the next instructions are followed however (and some ports will just never build no matter what).

 

[kencu]

As mentioned, gcc7 needs some tweaks to build properly for PPC SnowLeopard. Basically in a few places, you have to tell gcc7 to behave like Leopard instead of SnowLeopard, because the System in PPC SnowLeopard does not have the expected symbols and features that are found in the System on SnowLeopard 10.6.8. I did that with a patch in the gcc7 source code, and that is automatically added when you build gcc7 using my "Portfile Overlay" (new term, description coming shortly).

When using MacPorts, if you want to make changes to the ports to suit certain purposes you may have, you set up a folder that is laid out the way the MacPorts main portfile folder is set up. Then you tell MacPorts to look in your folder FIRST for a Portfile. If MacPorts finds your folder has the Portfile it is looking for (eg gcc7) then it will use that and stop looking. If MacPorts does not find a Portfile for the port it is looking for in your folder, then it goes on (falls back) to the main MacPorts portfile repository.

To do this, you generate the required folder in the required layout (very simple) and then then tell macports to use it.

I have made a folder of portfiles that are tweaked for PPC SnowLeopard, and I have uploaded that folder to here:

<https://github.com/kencu/PPCSnowLeopardPorts>

I have been doing this for a long time, years in fact, and you will find other overlays on that github site, but the only one you are interested in right now is PPCSnowLeopardPorts. You would download that folder (using git if you can, but some other way such as using a web browser if you can't use git yet on this system). Then you put that folder somewhere with permissions that MacPorts can accept. I like to use

/opt/PPCSnowLeopardPorts

so if you are following this along, I suggest you use that too. If you don't want to do what I suggest, and want to put that folder somewhere else, OK, but be careful about permissions -- it will often not work right if you put in your home folder somewhere, for example, because MacPorts has some trouble reading from there (sandboxing again -- your home folder is usually protected from MacPorts looking in there).

Then you tell MacPorts you want to use that folder as an overlay. To do that, you edit another configuration file (surprised? I think not ... ) /opt/local/etc/macports/sources.conf and you add your folder ABOVE the defaults portfile folder (so it will be found first). I added mine like this:

$ diff -u /opt/local/etc/macports/sources.conf.default /opt/local/etc/macports/sources.conf
--- /opt/local/etc/macports/sources.conf.default    2021-08-22 14:16:52.000000000 -0700
+++ /opt/local/etc/macports/sources.conf    2021-08-24 00:30:40.000000000 -0700
@@ -27,4 +27,7 @@
# sites, etc.), the primary MacPorts source must always be tagged
# "[default]", even if switched from the default "rsync://" URL.

+# override repo
+file:///opt/PPCSnowLeopardPorts
+
rsync://rsync.macports.org/macports/release/tarballs/ports.tar [default]

or, if diff files still seem hard to read to you, then the working part of the file looks like this now:

# For proper functionality of various resources (port groups, mirror
# sites, etc.), the primary MacPorts source must always be tagged
# "[default]", even if switched from the default "rsync://" URL.

# override repo
file:///opt/PPCSnowLeopardPorts

rsync://rsync.macports.org/macports/release/tarballs/ports.tar [default]

Now if you have got this far, you need to run "sudo port -v sync" one more time (to generate the PortIndex in my overlay repo that MacPorts will now use). This only takes a few seconds, because there are only 12 ports in there (so far) that I have had to tweak.

Now, if you are like me, more ports will build (the ones I fixed in that repo) and MacPorts will no longer try to use gcc11 on PPC SnowLeopard (which does not work). It will instead use gcc7/libgcc7 which does work. And when you try to install gcc7, you will use my very slightly patched version that appears to be correctly fixed for PPC SnowLeopard. If you are interested in the gcc7 patches needed, you can view them here:

PPCSnowLeopardPorts/patch-gcc7-darwin-config-for-PPCSL.diff at main · kencu/PPCSnowLeopardPorts

a local repository of MacPorts that are configured for an installation of Snow Leopard for PPC and shadow newer incompatible versions of ports - PPCSnowLeopardPorts/patch-gcc7-darwin-config-for-PPC...

github.com

If you are a gcc genius and can improve upon my tweaks, I welcome the input!

We are getting close now to a working setup, but we have one more tweak to make. MacPorts compiler selection will try to use clang compilers on SnowLeopard, but we need to force it to never use clang compilers on PPC SnowLeopard, as they don't work there. Also, MacPorts base will try to use gcc 11, 10, 9, and 8 on SnowLeopard, but on PPC SnowLeopard, we currently only have gcc7 working. To override this, the PPCSnowLeopardPorts overlay repo has made a few tiny edits to the compiler selection process in these files:

$ diff -ur /opt/macports-ports/_resources/port1.0/compilers /opt/PPCSnowLeopardPorts/_resources/port1.0/compilers
diff -ur /opt/macports-ports/_resources/port1.0/compilers/clang_compilers.tcl /opt/PPCSnowLeopardPorts/_resources/port1.0/compilers/clang_compilers.tcl
--- /opt/macports-ports/_resources/port1.0/compilers/clang_compilers.tcl    2021-08-24 22:45:43.000000000 -0700
+++ /opt/PPCSnowLeopardPorts/_resources/port1.0/compilers/clang_compilers.tcl    2021-08-29 19:13:24.000000000 -0700
@@ -11,7 +11,7 @@
# Clang 9.0 and newer only on 11+ (Darwin 20)

global os.major os.arch
-
+if { ${os.arch} ne "powerpc" } {
#if { $${os.major} >= 10 } {
     # TODO: evaluate compatibility of clang-{10,11} as defaults instead of 9.0
     #lappend compilers macports-clang-11
@@ -53,3 +53,4 @@
         lappend compilers macports-clang-3.3
     }
}
+}


diff -ur /opt/macports-ports/_resources/port1.0/compilers/gcc_compilers.tcl /opt/PPCSnowLeopardPorts/_resources/port1.0/compilers/gcc_compilers.tcl
--- /opt/macports-ports/_resources/port1.0/compilers/gcc_compilers.tcl    2021-08-24 22:45:43.000000000 -0700
+++ /opt/PPCSnowLeopardPorts/_resources/port1.0/compilers/gcc_compilers.tcl    2021-08-29 19:15:00.000000000 -0700
@@ -5,12 +5,12 @@

global os.major os.arch

-if { ${os.major} >= 10 } {
+if { ${os.major} >= 11 } {
     lappend compilers macports-gcc-11 macports-gcc-10
}

if { ${os.arch} ne "arm" } {
-    if { ${os.major} >= 10 } {
+    if { ${os.major} >= 11 } {
         lappend compilers macports-gcc-9 macports-gcc-8
     }
     if { ${os.major} < 20 } {

You can see that if the os.arch is "powerpc" (such as on PPC SnowLeopard) then clang compilers will never be selected. And the gcc compiler selection has been tweaked so the newer gcc versions past gcc7 are only used on Lion and above. So on our SnowLeopard system, gcc7 will be the newest one used (which works).

This is great, and now many more things will build.

But there is still one problem. The way MacPorts works, it will look in the directory where the portfile is for the _resources folder that contains the compiler selection code. So for all the ports that are still in the main MacPorts repo, it will look in that _resources folder instead of the one in PPCSnowLeopardPorts, and it will select the (wrong for us) default compilers again.

To fix that, you can edit the compiler selection as above in the main macports portfile repo as well (the folder of interest is here):

/opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/_resources/port1.0/compilers

Note, that every time you run "sudo port -v sync" that editing will be erased and the old defaults will be put back. So what I do is this after I run "sudo port -v sync"

$ sudo mv /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/_resources/port1.0/compilers /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/_resources/port1.0/compilers-moved
$ sudo ln -s /opt/PPCSnowLeopardPorts/_resources/port1.0/compilers /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/_resources/port1.0/compilers

And then the main MacPorts portfile repo will use the newer files we want to use in /opt/PPCSnowLeopardPorts/_resources/port1.0/compilers

There will be broken ports. Please don't report them to MacPorts bug tracker.

 

[B S Magnet]

As mentioned, gcc7 needs some tweaks to build properly for PPC SnowLeopard. Basically in a few places, you have to tell gcc7 to behave like Leopard instead of SnowLeopard, because the System in PPC SnowLeopard does not have the expected symbols and features that are found in the System on SnowLeopard 10.6.8. I did that with a patch in the gcc7 source code, and that is automatically added when you build gcc7 using my "Portfile Overlay" (new term, description coming shortly).

When using MacPorts, if you want to make changes to the ports to suit certain purposes you may have, you set up a folder that is laid out the way the MacPorts main portfile folder is set up. Then you tell MacPorts to look in your folder FIRST for a Portfile. If MacPorts finds your folder has the Portfile it is looking for (eg gcc7) then it will use that and stop looking. If MacPorts does not find a Portfile for the port it is looking for in your folder, then it goes on (falls back) to the main MacPorts portfile repository.

To do this, you generate the required folder in the required layout (very simple) and then then tell macports to use it.

I have made a folder of portfiles that are tweaked for PPC SnowLeopard, and I have uploaded that folder to here:

<https://github.com/kencu/PPCSnowLeopardPorts>

I have been doing this for a long time, years in fact, and you will find other overlays on that github site, but the only one you are interested in right now is PPCSnowLeopardPorts. You would download that folder (using git if you can, but some other way such as using a web browser if you can't use git yet on this system). Then you put that folder somewhere with permissions that MacPorts can accept. I like to use

/opt/PPCSnowLeopardPorts

so if you are following this along, I suggest you use that too. If you don't want to do what I suggest, and want to put that folder somewhere else, OK, but be careful about permissions -- it will often not work right if you put in your home folder somewhere, for example, because MacPorts has some trouble reading from there (sandboxing again -- your home folder is usually protected from MacPorts looking in there).

Then you tell MacPorts you want to use that folder as an overlay. To do that, you edit another configuration file (surprised? I think not ... ) /opt/local/etc/macports/sources.conf and you add your folder ABOVE the defaults portfile folder (so it will be found first). I added mine like this:

$ diff -u /opt/local/etc/macports/sources.conf.default /opt/local/etc/macports/sources.conf
--- /opt/local/etc/macports/sources.conf.default    2021-08-22 14:16:52.000000000 -0700
+++ /opt/local/etc/macports/sources.conf    2021-08-24 00:30:40.000000000 -0700
@@ -27,4 +27,7 @@
# sites, etc.), the primary MacPorts source must always be tagged
# "[default]", even if switched from the default "rsync://" URL.

+# override repo
+file:///opt/PPCSnowLeopardPorts
+
rsync://rsync.macports.org/macports/release/tarballs/ports.tar [default]

or, if diff files still seem hard to read to you, then the working part of the file looks like this now:

# For proper functionality of various resources (port groups, mirror
# sites, etc.), the primary MacPorts source must always be tagged
# "[default]", even if switched from the default "rsync://" URL.

# override repo
file:///opt/PPCSnowLeopardPorts

rsync://rsync.macports.org/macports/release/tarballs/ports.tar [default]

Now if you have got this far, you need to run "sudo port -v sync" one more time (to generate the PortIndex in my overlay repo that MacPorts will now use). This only takes a few seconds, because there are only 12 ports in there (so far) that I have had to tweak.

Now, if you are like me, more ports will build (the ones I fixed in that repo) and MacPorts will no longer try to use gcc11 on PPC SnowLeopard (which does not work). It will instead use gcc7/libgcc7 which does work. And when you try to install gcc7, you will use my very slightly patched version that appears to be correctly fixed for PPC SnowLeopard. If you are interested in the gcc7 patches needed, you can view them here:

PPCSnowLeopardPorts/patch-gcc7-darwin-config-for-PPCSL.diff at main · kencu/PPCSnowLeopardPorts

a local repository of MacPorts that are configured for an installation of Snow Leopard for PPC and shadow newer incompatible versions of ports - PPCSnowLeopardPorts/patch-gcc7-darwin-config-for-PPC...

github.com

If you are a gcc genius and can improve upon my tweaks, I welcome the input!

We are getting close now to a working setup, but we have one more tweak to make. MacPorts compiler selection will try to use clang compilers on SnowLeopard, but we need to force it to never use clang compilers on PPC SnowLeopard, as they don't work there. Also, MacPorts base will try to use gcc 11, 10, 9, and 8 on SnowLeopard, but on PPC SnowLeopard, we currently only have gcc7 working. To override this, the PPCSnowLeopardPorts overlay repo has made a few tiny edits to the compiler selection process in these files:

$ diff -ur /opt/macports-ports/_resources/port1.0/compilers /opt/PPCSnowLeopardPorts/_resources/port1.0/compilers
diff -ur /opt/macports-ports/_resources/port1.0/compilers/clang_compilers.tcl /opt/PPCSnowLeopardPorts/_resources/port1.0/compilers/clang_compilers.tcl
--- /opt/macports-ports/_resources/port1.0/compilers/clang_compilers.tcl    2021-08-24 22:45:43.000000000 -0700
+++ /opt/PPCSnowLeopardPorts/_resources/port1.0/compilers/clang_compilers.tcl    2021-08-29 19:13:24.000000000 -0700
@@ -11,7 +11,7 @@
# Clang 9.0 and newer only on 11+ (Darwin 20)

global os.major os.arch
-
+if { ${os.arch} ne "pcc" } {
#if { $${os.major} >= 10 } {
     # TODO: evaluate compatibility of clang-{10,11} as defaults instead of 9.0
     #lappend compilers macports-clang-11
@@ -53,3 +53,4 @@
         lappend compilers macports-clang-3.3
     }
}
+}
\ No newline at end of file
diff -ur /opt/macports-ports/_resources/port1.0/compilers/gcc_compilers.tcl /opt/PPCSnowLeopardPorts/_resources/port1.0/compilers/gcc_compilers.tcl
--- /opt/macports-ports/_resources/port1.0/compilers/gcc_compilers.tcl    2021-08-24 22:45:43.000000000 -0700
+++ /opt/PPCSnowLeopardPorts/_resources/port1.0/compilers/gcc_compilers.tcl    2021-08-29 19:15:00.000000000 -0700
@@ -5,12 +5,12 @@

global os.major os.arch

-if { ${os.major} >= 10 } {
+if { ${os.major} >= 11 } {
     lappend compilers macports-gcc-11 macports-gcc-10
}

if { ${os.arch} ne "arm" } {
-    if { ${os.major} >= 10 } {
+    if { ${os.major} >= 11 } {
         lappend compilers macports-gcc-9 macports-gcc-8
     }
     if { ${os.major} < 20 } {

You can see that if the os.arch is "ppc" (such as on PPC SnowLeopard) then clang compilers will never be selected. And the gcc compiler selection has been tweaked so the newer gcc versions past gcc7 are only used on Lion and above. So on our SnowLeopard system, gcc7 will be the newest one used (which works).

This is great, and now many more things will build.

But there is still one problem. The way MacPorts works, it will look in the directory where the portfile is for the _resources folder that contains the compiler selection code. So for all the ports that are still in the main MacPorts repo, it will look in that _resources folder instead of the one in PPCSnowLeopardPorts, and it will select the (wrong for us) default compilers again.

To fix that, you can edit the compiler selection as above in the main macports portfile repo as well (the folder of interest is here):

/opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/_resources/port1.0/compilers

Note, that every time you run "sudo port -v sync" that editing will be erased and the old defaults will be put back. So what I do is this after I run "sudo port -v sync"

$ sudo mv /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/_resources/port1.0/compilers /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/_resources/port1.0/compilers-moved
$ sudo ln -s /opt/PPCSnowLeopardPorts/_resources/port1.0/compilers /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/_resources/port1.0/compilers

And then the main MacPorts portfile repo will use the newer files we want to use in /opt/PPCSnowLeopardPorts/_resources/port1.0/compilers

Finally, you will note I always keep saying to use

sudo port -v sync

instead of

sudo port -v selfupdate

that is because for the moment we NEVER want to update MacPorts base code (the edit we made to the sandboxing file will be removed and the default would return). If you do accidentally run

sudo port -v selfupdate

no big harm done. Just do the edit to portsandbox.tcl again.

After that, lots of ports will build. There are hiccups and you can expect more, but many of them will be fixable with a look at the portfile that is failing for you. You can usually spot in a few seconds why it might be failing, if it is just configuration thing where the Portfile expects i386. If the issue is the older SDK on PPC SnowLeopard does not match the SDK found in SnowLeopard 10.6.8, well that is harder to fix.

You can view and edit a portfile like this:

bbedit `port file MYPORTFILE`

if you make some some changes to Portfiles in the main macports collection, it's OK. They will disappear every time you run

sudo port -v sync

Don't forget to make the symlink to our new compilers folder after you sync, or the compiler selection will be wrong! See above.

I hope this helps some or most of you get some current ports built. I know a few of you have been eagerly awaiting this information. I wanted to have it as workable as possible before I offered it up. Some of you might find it plainly too confusing, at least for now, and prefer to cob over binaries built on PPC Leopard instead. That is just fine if you want to do that... that is what I originally recommended to people, as it is trivially easy to do.

But I was intrigued by PPC SnowLeopard, and set it up, so I thought I would share how to do this for anyone who is interested.

There will be broken ports. Please don't report them to MacPorts bug tracker or they will think you foolish and me foolisher for telling you how to do this :>

Thank you for finally and actually walking through all of this on your own, and thank you for also sharing with us the several steps you followed and undertook to render Macports to be somewhat usable within this particularly unique case environment. It is much appreciated.

The WikiPost has been updated to reflect this workaround.

 

[kencu]

OK, I've had some fun with the PPC SnowLeopard system, but it's time to wrap things up and bring the G5 I had dedicated to this cause for the last few days back to the mainstream of fixing ports for Tiger and Leopard PPC for MacPorts users.

In the PPCSnowLeopardPorts repo I spent a bit of extra time first importing the unaltered Portfile and then showing the change needed, so that someone interested could see what was done to fix the build.

If you fix more ports and want to try sending them up for inclusion in that PPCSnowLeopardPorts repository, feel free to open a PR and I'll look it over from time to time.

I would encourage each and every one of you to become active in the MacPorts community. There are a number of interested people there who often know a great deal about how to fix software for these older systems, and MacPorts is pretty much the only game in town for current software on systems running macOS < Mojave.

Cheers!

 

[kencu]

I see someone edited the first wikipost about MacPorts on this platform, and mentioned "MacPorts inner workings".

I realize I was very complete in my descriptions, but perhaps it might be helpful to people if it said something like "MacPorts works normally on this platform with a few minor adjustments, although not all ports will build", as the real fix to MacPorts (minus the explanation) takes less than five minutes.

That probably better describes the situation as I would see it, but up to you folks.

 

[B S Magnet]

I see someone edited the first wikipost about MacPorts on this platform, and mentioned "MacPorts inner workings".

I realize I was very complete in my descriptions, but perhaps it might be helpful to people if it said something like "MacPorts works normally on this platform with a few minor adjustments, although not all ports will build".

That probably better describes the situation as I would see it, but up to you folks.

I already discussed this above.

While you were thorough with your description in post #1114 (a welcomed departure from several earlier posts precipitating your involvement, thank you), it is not going to be useful for everyone who’s experimenting with SL-PPC on their own. Fortunately, there are a couple of paths they can now try out, and both are documented in the WikiPost (note: anyone can update the WikiPost).

And while Macports may be a domain with which you have intimate familiarity as a developer, it is not reasonable to expect that most participants in this forum are going to have that level of hands-on involvement and, thus, not reasonable to presume that what may be “minor” or “simple” or “easy” for you is going to be so for anyone else. To lead with that presumption is to err on the side of hubris, which in the end is not helpful to anyone, not even yourself.

 

[barracuda156]

Could anyone say if it is possible to install R on 10.6 PPC? Preferably recent versions of R, like 3.x or 4.x.

Another thing I am interested in is Stan for R (rstan). Does it install?

RStan

mc-stan.org

 

[kencu]

Could anyone say if it is possible to install R on 10.6 PPC? Preferably recent versions of R, like 3.x or 4.x.

As a loose rule-of-thumb, if a port installs now on both 10.5 PPC and 10.6 Intel, the chance of it building directly on 10.6 PPC is high. Some tweaking may still be required. If a port installs on neither 10.5 PPC nor 10.6 Intel, chances are slim.

 

[barracuda156]

As a loose rule-of-thumb, if a port installs now on both 10.5 PPC and 10.6 Intel, the chance of it building directly on 10.6 PPC is high. Some tweaking may still be required. If a port installs on neither 10.5 PPC nor 10.6 Intel, chances are slim.

There are several versions of R 3.x.x for 10.6 Intel (latest seems to be 3.2.1): https://cran.r-project.org/bin/macosx/old/

However for PPC only R 2.x.x.

 

[kencu]

Oh, I thought you were trying to build it.

If you are instead trying to run a prebuilt binary downloaded from the internet somewhere, the last version you can find with PPC code in it is your best bet.

 

[barracuda156]

Oh, I thought you were trying to build it.

If you are instead trying to run a prebuilt binary downloaded from the internet somewhere, the last version you can find with PPC code in it is your best bet.

I am going to build it, if that is possible.

The issue is that I want to buy PowerMac G5 – mostly because I wanted it back in 2004–2005, but went with Mac Pro instead, however I need R for my research. If at least R 3.x.x can run on it, I can go ahead and by G5.

P. S. I do not imply that someone else has to find out this for me of course. I just thought that somebody may have tried that already, since R is arguably the most popular statistical platform nowadays.

 

[kencu]

Well here then, it might not be a totally lost cause to build on a PPC system, but it also doesn't look too encouraging.

R | MacPorts

ports.macports.org

There is a green check by Leopard PPC, but unfortunately that doesn't necessarily mean it built. What the green check means is that it didn't fail to build -- if the Portfile disallows building on that system, you can get a green check. (That's not helpful, but the coding to make it smarter hasn't been written yet in the web app that we use).

The last build attempt on 10.6 failed, but I don't think it looks totally impossible to dig deeper on...it was some kind of compiler setting hiccup, rather than a "hard fail".

Log File contents

checking how to get verbose linking output from /opt/local/bin/gfortran-mp-11... configure: WARNING: compilation failed

checking for Fortran libraries of /opt/local/bin/gfortran-mp-11...
checking how to get verbose linking output from /opt/local/bin/clang-mp-11... configure: WARNING: cannot determine how to obtain linking information from /opt/local/bin/clang-mp-11

checking for C libraries of /opt/local/bin/clang-mp-11...
checking for dummy main to link with Fortran libraries... none
checking for Fortran name-mangling scheme... configure: error: in `/opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_math_R/R/work/R-4.1.1':
configure: error: cannot compile a simple Fortran program
See `config.log' for more details

what really happened is buried in the config.log and we can't see that.

So -- perhaps not hopeless to build the current version.

 

[kencu]

I was curious, so I built R on 10.6 SnowLeopard Intel locally without any trouble:

$ port -v installed R
The following ports are currently installed:
R @4.1.1_0+builtin_lapack+cairo+gcc11+openmp+recommended+x11 (active) requested_variants='' platform='darwin 10' archs='x86_64' date='2021-09-06T20:49:01-0700'

and then, with that success, I logged in to the MacPorts buildbot farm and bumped the 10.6 x86_64 builder there, and it failed again with the same error as before. So -- it builds, but something I can't see locally is failing on the buildbot.

Still, encouraging for you perhaps. That's not building it on PPC of course -- who knows what might show up when you try to do that -- but it's close to what you hope for.