Snow Leopard on Unsupported PowerPC Macs

[barracuda156]

Hi @barracuda156!

I’m happy to test this for you but will need a couple days as i’m working all weekend and will need to setup another 10A190 partition - i have 10A096, 10A190, 10A222, 10A432 (intel) and 10.6.8 (intel) setup across 5 or 6 different systems and different modifications and binary changes on all of them so will need a fresh partition to provide reliable results for you.

Thank you.

In principle it should not matter for the purpose of testing if anything has been modified in the OS. As long as you have a 10a190+ without MacPorts installed, it should be fine.

If everything is downloaded and nothing is built from source, consider test passed. At the moment we are not interested in binary compatibility issues etc.

(The current version will likely not work in Rosetta due to a bug in the base 2.9.x. I had no time to address that. I could make a version for Rosetta if anyone needs it though.)

 

[linuxman1000]

One small thing, I've noticed that @educovas has taken down the Mega link for his images. If it isn't any trouble, would someone be so kind as to re-upload them to somewhere like macintoshgarden.org? No pressure, though, everyone seems to be pretty wrapped up right now with testing/work stuff.

 

[barracuda156]

@barracuda156 seems to be working so far on @educovas modified 10A222 imaged to a PowerBook G4 (PowerBook5,6). Will report more detailed findings as i'm able. For anyone looking to do this, Xcode Command Line Tools must be installed.

View attachment 2379612View attachment 2379614

Awesome, thank you very much for trying it out!

If anything up to CMake does not install pre-built, that will mean I have missed building some default variant, so please let me know.

Myself I am using -devel versions of many ports, plus custom variants of cctools, ld64 and libgcc. So that is my concern here, we do not want a user to be forced to build libgcc or smth like that from scratch.

I will still need to provide G4-optimized version of some ports, but for now I hope that the set-up is functional.

 

[ojfd]

One small thing, I've noticed that @educovas has taken down the Mega link for his images.

The thing is not that small..

 

[ChrisCharman]

Awesome, thank you very much for trying it out!

If anything up to CMake does not install pre-built, that will mean I have missed building some default variant, so please let me know.

Myself I am using -devel versions of many ports, plus custom variants of cctools, ld64 and libgcc. So that is my concern here, we do not want a user to be forced to build libgcc or smth like that from scratch.

I will still need to provide G4-optimized version of some ports, but for now I hope that the set-up is functional.

Took all night for vsync to do its thing but once it was done Cmake-devel and the dependency packages started to download from the custom url. The package install failed once it reached OpenSSL because it detected a version of Xcode earlier than 3.2.6. Mpstats also would not install. Seems like you’re on the right track with this though as several ports did install correctly mate.

 

[barracuda156]

Took all night for vsync to do its thing but once it was done Cmake-devel and the dependency packages started to download from the custom url. The package install failed once it reached OpenSSL because it detected a version of Xcode earlier than 3.2.6. Mpstats also would not install. Seems like you’re on the right track with this though as several ports did install correctly mate.


View attachment 2379716

I will check locally.

But isn’t the list showing OpenSSL as installed already? What is the exact error you get?

(Of course OpenSSL builds and works fine, but maybe I did not build the latest version yet, I will do check that and build now, if it is missing.)

 

[ChrisCharman]

I will check locally.

But isn’t the list showing OpenSSL as installed already? What is the exact error you get?

(Of course OpenSSL builds and works fine, but maybe I did not build the latest version yet, I will do check that and build now, if it is missing.)

Just getting ready to go to work mate but to be clear, dependencies for CMake installed up to OpenSSL then the install command stopped trying to install Cmake due to the below 3.2.6 Xcode detected.

 

[barracuda156]

Just getting ready to go to work mate but to be clear, dependencies for CMake installed up to OpenSSL then the install command stopped trying to install Cmake due to the below 3.2.6 Xcode detected.

Ok, thank you. I will just wipe out all ports from a PowerBook with 10a190 and try reproducing exactly the same.

Something is not working right, since there is no requirement for Xcode to be 3.2.6+ (if someone has added it, it must be removed, of course).

 

[barracuda156]

Also, i have tried installed the 10A190 on my DC 2.3 on a seperate SSD. The reason was to test the apps that i use, DAWs, VSTs. I have encountered problems with some software (not working, breaking, working poorly), so im patiently waiting for releases made by @educovas and @barracuda156 without bothering them.
In the future I plan to test everything with all software i use and have mentioned.
The bad part is that i don't program for Macs (never have), but i programm RISC microcontrollers like STM32 and PICs.

For open-source software, I think, at the moment we have a better support for 10a190 than for 10.5.8. (Of course, with commercial apps of the period situation is reverse, and some apps stupidly fail to launch or use a wrong API, and we cannot do anything about that due to closed sources.)

If in “not working, breaking, working poorly” you refer to open-source software and a comparison against 10.5.8 is implied, you could raise those issues in this thread, for example, and we can try addressing those.

Also, if something of the software which you actually want to use fails to build on PowerPC, but in principle should build, that may also be addressed. (I mean, it is pointless to report something requiring Rust, bleeding-edge SDK, Intel SIMD or Qt6, we know those won’t build.)

 

[ChrisCharman]

Ok, thank you. I will just wipe out all ports from a PowerBook with 10a190 and try reproducing exactly the same.

Something is not working right, since there is no requirement for Xcode to be 3.2.6+ (if someone has added it, it must be removed, of course).

Quick update; reinstalled Xcode 3.2 pre-release from 10A190 fixed it. Seems to be functioning properly now so must have been an issue with the Xcode that was installed. Will test more thoroughly when i get back from work.

 

[barracuda156]

Quick update; reinstalled Xcode 3.2 pre-release from 10A190 fixed it. Seems to be functioning properly now so must have been an issue with the Xcode that was installed. Will test more thoroughly when i get back from work.

Anything beyond Xcode from 10a222 is untested. I have installed Xcode from 10a261 (I think) once, but more stuff was broken there, while benefits were not obvious, so I downgraded back to 10a222 (with replacements from 10a190). Even then, some things do not work correctly, but I seldom need an actual Xcode, and Unix-tools are fine.
I think in rare instances the build compares OS version to SDK version which Xcode reports, and mismatch of those causes issues. So generally speaking, I would advise to stay on Xcode from 10a190 for the better user experience. (To be honest, it is unclear if having Xcode from 10a222 gives any benefit at all.)

It may be sensible to replace gcc-4.2 and some/all Unix-tools with versions from 10.6.8 and/or rebuilt from sources ones, but that gonna be a substantial effort with unclear benefit.

 

[ChrisCharman]

Anything beyond Xcode from 10a222 is untested. I have installed Xcode from 10a261 (I think) once, but more stuff was broken there, while benefits were not obvious, so I downgraded back to 10a222 (with replacements from 10a190). Even then, some things do not work correctly, but I seldom need an actual Xcode, and Unix-tools are fine.
I think in rare instances the build compares OS version to SDK version which Xcode reports, and mismatch of those causes issues. So generally speaking, I would advise to stay on Xcode from 10a190 for the better user experience. (To be honest, it is unclear if having Xcode from 10a222 gives any benefit at all.)

It may be sensible to replace gcc-4.2 and some/all Unix-tools with versions from 10.6.8 and/or rebuilt from sources ones, but that gonna be a substantial effort with unclear benefit.

Yeah i rebuild all tools from AOSP as i’m building system components on the command line and install Xcode 3.2 preview from 10A190 to get things started.

The error was on 10A222 (@educovas) image, which was only recently restored, and was due to an installation error of the Xcode tools.

FYI for anyone following along, though it’s possible to install Xcode 3.1.4 from Leopard, it is inadvisable as the tools are outdated for building 10.6 binaries for the most part nor will it work with @barracuda156’s MacPorts.

 

[internetzel]

It may be sensible to replace gcc-4.2 and some/all Unix-tools with versions from 10.6.8 and/or rebuilt from sources ones, but that gonna be a substantial effort with unclear benefit.

I can highly recommend using apple-gcc42 @5666.3_16 +gpl3, as that is official gcc 4.2.4 with of Apple's patches for gcc 4.2.1 (latest version "usable" for Apple because of license issues). I had created that +gpl3 variant and had it added to MacPorts because of bugs in gcc 4.2.1 which broke Leopard WebKit.
That is the only gcc 4.2 version I can recommend to use - anything else will sooner or later cause trouble. Again, do not use other versions of gcc 4.2!

Regarding ld64, I also had to patch it for the same reason and had the patches included in the ld64-97 port. If I remember correctly, while I could get ld64-127 to work for ppc (I don't remember if I had created some bug fixes regarding ppc support), but back than it could not create a working Leopard WebKit and I couldn't track down the bugs in order to fix them. After all, as the patched ld64-97 working so reliably I didn't see the sense in diving deeper into fixing ld64-127.
So likewise, if the situation hasn't changed since then, ld64-97 (with my patches) is the only ld64 version I can recommend to use. Do not use other versions of ld64!

Did anything change with respect to gcc 4.2 and ld64 since my Leopard WebKit days?

 

[ChrisCharman]

I can highly recommend using apple-gcc42 @5666.3_16 +gpl3, as that is official gcc 4.2.4 with of Apple's patches for gcc 4.2.1 (latest version "usable" for Apple because of license issues). I had created that +gpl3 variant and had it added to MacPorts because of bugs in gcc 4.2.1 which broke Leopard WebKit.
That is the only gcc 4.2 version I can recommend to use - anything else will sooner or later cause trouble. Again, do not use other versions of gcc 4.2!

Regarding ld64, I also had to patch it for the same reason and had the patches included in the ld64-97 port. If I remember correctly, while I could get ld64-127 to work for ppc (I don't remember if I had created some bug fixes regarding ppc support), but back than it could not create a working Leopard WebKit and I couldn't track down the bugs in order to fix them. After all, as the patched ld64-97 working so reliably I didn't see the sense in diving deeper into fixing ld64-127.
So likewise, if the situation hasn't changed since then, ld64-97 (with my patches) is the only ld64 version I can recommend to use. Do not use other versions of ld64!

Did anything change with respect to gcc 4.2 and ld64 since my Leopard WebKit days?

Thanks @internetzel! Do you happen to have these patches archived at all? I’ve only compiled the gcc versions in the 10.6.0 source tree so will build the versions you recommended.

 

[barracuda156]

I can highly recommend using apple-gcc42 @5666.3_16 +gpl3, as that is official gcc 4.2.4 with of Apple's patches for gcc 4.2.1 (latest version "usable" for Apple because of license issues). I had created that +gpl3 variant and had it added to MacPorts because of bugs in gcc 4.2.1 which broke Leopard WebKit.
That is the only gcc 4.2 version I can recommend to use - anything else will sooner or later cause trouble. Again, do not use other versions of gcc 4.2!

Regarding ld64, I also had to patch it for the same reason and had the patches included in the ld64-97 port. If I remember correctly, while I could get ld64-127 to work for ppc (I don't remember if I had created some bug fixes regarding ppc support), but back than it could not create a working Leopard WebKit and I couldn't track down the bugs in order to fix them. After all, as the patched ld64-97 working so reliably I didn't see the sense in diving deeper into fixing ld64-127.
So likewise, if the situation hasn't changed since then, ld64-97 (with my patches) is the only ld64 version I can recommend to use. Do not use other versions of ld64!

Did anything change with respect to gcc 4.2 and ld64 since my Leopard WebKit days?

ld64-97 works better than ld64-127, I agree here, and AFAIK, Iain holds the same opinion.
So yes, I have been using ld64-97 on all my powerpc systems.

I build it against llvm-7.1.1 now though, and on ppc64 before I built it with llvm-5.0 (llvm-3.x are broken for ppc64 not just in sense of not generating correct code, but not even building). But for the most part llvm is inconsequential here (in theory it should be, but in practice I have seen a few cases where it appeared to make a difference).

gcc-4.2 from MacPorts never built for me on 10.6 ppc, though I never put efforts into fixing it (and a simple fix to darwin.h failed to help). I never saw much point in bothering with it, to be honest, and have been considering getting rid of archaic gccs completely: i.e., use them exclusively to bootstrap gcc-10, and isolate from the environment, so that neither they nor system libstdc++ ever get picked or linked to. That should free us from malloc nightmare which is otherwise rather annoying and affects numerous ports.
I am not sure which exactly version I tried to build, but likely whatever MacPorts had as the default.

Perhaps the only scenario where Apple gcc would matter is rebuilding xnu and other OS components. If I am at that point, I will likely try again to fix it for 10.6 ppc. Though I am not really sure if it will be better to use a newer gcc than the OS itself. Say, if the reference is 10A222, it might be better to use the native gcc of that build.

 

[barracuda156]

FYI for anyone following along, though it’s possible to install Xcode 3.1.4 from Leopard, it is inadvisable as the tools are outdated for building 10.6 binaries

That was an odd idea from the very beginning, given that the same image of 10A190 system which everyone used had its Xcode. It might have allowed to hack around a few failures by cheating the build into thinking it is on 10.5, but even then it was a wrong way to do that. Using newer Xcode could make sense, at least in some scenarios, not the older (one can always build for the earlier SDK, if needed, using a newer Xcode).

 

[ChrisCharman]

That was an odd idea from the very beginning, given that the same image of 10A190 system which everyone used had its Xcode. It might have allowed to hack around a few failures by cheating the build into thinking it is on 10.5, but even then it was a wrong way to do that. Using newer Xcode could make sense, at least in some scenarios, not the older (one can always build for the earlier SDK, if needed, using a newer Xcode).

I installed it to test compatibility and examine the binaries @barracuda156. I’ve been using 10A190 version of Xcode updated with compiled versions of the build tools from the 10.6.0 tree for years. Was just an experiment as i’m sure someone will come along and download either 10A096, 10A190 or 10A222 and attempt to install the older version given that it is the last officially supported PowerPC version of Xcode.

 

[ChrisCharman]

ld64-97 works better than ld64-127, I agree here, and AFAIK, Iain holds the same opinion.
So yes, I have been using ld64-97 on all my powerpc systems.

I build it against llvm-7.1.1 now though, and on ppc64 before I built it with llvm-5.0 (llvm-3.x are broken for ppc64 not just in sense of not generating correct code, but not even building). But for the most part llvm is inconsequential here (in theory it should be, but in practice I have seen a few cases where it appeared to make a difference).

gcc-4.2 from MacPorts never built for me on 10.6 ppc, though I never put efforts into fixing it (and a simple fix to darwin.h failed to help). I never saw much point in bothering with it, to be honest, and have been considering getting rid of archaic gccs completely: i.e., use them exclusively to bootstrap gcc-10, and isolate from the environment, so that neither they nor system libstdc++ ever get picked or linked to. That should free us from malloc nightmare which is otherwise rather annoying and affects numerous ports.
I am not sure which exactly version I tried to build, but likely whatever MacPorts had as the default.

Perhaps the only scenario where Apple gcc would matter is rebuilding xnu and other OS components. If I am at that point, I will likely try again to fix it for 10.6 ppc. Though I am not really sure if it will be better to use a newer gcc than the OS itself. Say, if the reference is 10A222, it might be better to use the native gcc of that build.

The archaic versions are a requirement for building system components, including GCC 3.3.

 

[barracuda156]

The archaic versions are a requirement for building system components, including GCC 3.3.

gcc-3.x should not be needed for 10.6 or even 10.5, it is gone for good with Tiger.
gcc-4.x is needed.

 

[barracuda156]

I installed it to test compatibility and examine the binaries @barracuda156. I’ve been using 10A190 version of Xcode updated with compiled versions of the build tools from the 10.6.0 tree for years. Was just an experiment as i’m sure someone will come along and download either 10A096, 10A190 or 10A222 and attempt to install the older version given that it is the last officially supported PowerPC version of Xcode.

I was not referring to you; I remember using Xcode 3.1.4 was mentioned or even recommended by someone here earlier.

 

[ChrisCharman]

I was not referring to you; I remember using Xcode 3.1.4 was mentioned or even recommended by someone here earlier.

Yeah that’s why i was testing it out.

 

[ChrisCharman]

gcc-3.x should not be needed for 10.6 or even 10.5, it is gone for good with Tiger.
gcc-4.x is needed.

It’s useful still, but not essential for 10.6 - GCC4.0 and GCC4.2 are needed for Snow Leopard but as we’re working with older hardware and using and building older components it’s worth keeping around in order to build stuff from the source tree that requires it. Not needed for MacPorts stuff at all though, so you can safely ignore it.

 

[barracuda156]

It’s useful still, but not essential for 10.6 - GCC4.0 and GCC4.2 are needed for Snow Leopard but as we’re working with older hardware and using and building older components it’s worth keeping around in order to build stuff from the source tree that requires it. Not needed for MacPorts stuff at all though, so you can safely ignore it.

This is a side topic, but since we touched on it anyway: Outside of building OS components (and bootstrapping a modern compiler) Xcode gccs are arguably unneeded for building third-party software, whether via MacPorts or not.
While we do use gcc-4.2 on ppc in MacPorts whenever a newer standard is not required, 10.6 Intel was switched to clang-11 as the default compiler and even libc++. And while I am not convinced libc++ was an optimal choice (at least an archaic one which is used currently), clang-11 works fine, and there are no failures due to a lack of C11/C++11 support, while on ppc we have those on a regular basis.

The only reason I am not doing that (switch to gcc13+ with modern libstdc++) is that it will require a massive rebuild of everything which used gcc-4.2. (Not sure why MacPorts folks did not do that; maybe simply no one thought about ppc.)

 

[ChrisCharman]

This is a side topic, but since we touched on it anyway: Outside of building OS components (and bootstrapping a modern compiler) Xcode gccs are arguably unneeded for building third-party software, whether via MacPorts or not.
While we do use gcc-4.2 on ppc in MacPorts whenever a newer standard is not required, 10.6 Intel was switched to clang-11 as the default compiler and even libc++. And while I am not convinced libc++ was an optimal choice (at least an archaic one which is used currently), clang-11 works fine, and there are no failures due to a lack of C11/C++11 support, while on ppc we have those on a regular basis.

The only reason I am not doing that (switch to gcc13+ with modern libstdc++) is that it will require a massive rebuild of everything which used gcc-4.2. (Not sure why MacPorts folks did not do that; maybe simply no one thought about ppc.)

Yeah i’m aware of all of that already. I’m exclusively working on the OS on this project though so third party stuff isn’t on the horizon for me. You’re the one leading the MacPorts stuff, which i’m sure will be much appreciated by all the people that want to download and run newer software on 10.6 PowerPC down the line. I point out OS exclusive stuff when you post in this thread as the MacPorts development stuff has its own thread and those that want to chip in and get involved helping rebuild the OS need to know that there is a difference between what you’re working on and referencing regarding MacPorts and the OS specific stuff.

 

[ojfd]

Ahem.. It would be extremely nice of you, guys, if you now and then would throw in a sentence or two that a non-programmer also could understand and follow the thread, which, btw, is in PowerPC (for mortals) and not in Developers forum.
Thank you!