Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
{01-FEB-2020} SMtube 20.1.0 (OS X 10.4 ) (alternative for Youview/Mactubes/Mobile Youtube) INSTALLER
- Thread starter Lastic
- Start date
- Sort by reaction score
Do you have any details on this matter? The fact that it compiles successfully on 10.4 or 10.5 is already a significant achievement. Many applications struggle to build due to the lack of a more modern version of GCC or Qt.
I’m eager to learn more. Perhaps there is a possibility to port some components or dependencies.
We have the latest GCC possible, but Qt is limited to Qt4, as of now. I think Konqueror is anyway KDE4? So it uses Qt4.
Some other Qt4-based apps have issues with accessing the web, either partly or completely. Could be a problem with their interface to OpenSSL or the way they are built.
However since at least Arora browser works, that should be possible in principle for other Qt4-based browsers.
Everything is in MacPorts, if you wanna try, but you should use a previous version of raptor2, otherwise soprano will be broken, and nothing of KDE4 gonna build. Pick it from my repo or go back in history in MacPorts master.
P. S. If you are interested in getting KDE to work on Darwin ppc, lumme know. There are some issues with akonadi and pimlibs which have to be addressed: I have some KDE4 apps working normally by now, but a large chunk are broken. They build but crash.
If that is fixed, we may get some noticeable improvements: better email client, iTunes replacement, photo management etc.
Though strictly for web-browsing I think Qt4 is a lost case, and we should rather concentrate on either getting Palemoon working or, perhaps substantially harder task, to get V8 fixed and try some Chromium-based browser. (I have fixed the build of V8, but it does not seem to be functional atm. Likely needs better fixes for assembler part.)
Excuse my ignorance, but what is preventing us from having Qt5? And what is stopping Qt4 from utilizing a more modern version of OpenSSL?
I must admit that I'm quite new to being limited to older software, as I mostly use Linux in my day-to-day life. I'm also a bit rusty when it comes to Mac OS X; I basically haven't used it since they changed the name to "macOS."
Playing around with PowerPC Macintoshes and older operating systems is a hobby of mine, but I'm certainly not an expert. I've only really used MacPorts and Homebrew to get a handful of packages installed.
I'm definitely interested in learning more about this and gaining some hands-on experience, even if it's just to try something new and write an article about it for my website. So, where do I start?
Enormous efforts of Qt upstream to ensure Qt5 is broken
Not even joking. They did everything for it not to work: hardcoded MacOS to Cocoa, removed support for 32-bit, removed Carbon codepath, never bothered to test builds with gcc (so it does not work, of course), heavily used SDK features of a few bleeding edge macOS versions at any given time without bothering to have fallbacks and even dumping fallback code which happened to exist etc.
On top of that a completely retarded build system, making any attempts to fix upstream bugs as painful as it gets.
The last Qt5 which someone could build on 10.6 x86_64 (!) with clang (!) was 5.3. Even if we fix that one for gcc and powerpc, 5.3 is pretty much of no use now, as modern software typically requires much later versions. Those, in turn, are broken on much later macOS versions.
IMO, the only feasible pathway will be to switch Qt to X11 backend, completely getting rid of hopelessly broken Cocoa. That should be doable, but a) we need to hack the code, because upstream does not want anyone to be able to choose GUI backend, and b) even if GUI is switched to X11, the code base still uses some Apple-specific headers and Cocoa files, which, unsurprisingly, again may fail to compile (I say “may” here, because I did not try every Qt version), so we need to fix those or replace with generic Unix versions, provided those gonna work.
This should be done for multiple components, just having qtbase is nowhere enough.
To put this into context, X11 builds are broken on macOS in general (and perhaps never worked), so it is not just about fixing something specifically for ppc. We need to start from fixing X11 at least for some macOS version, then fix building with gcc, SDK issues, bitness and endianness, and then start checking if something can actually link against that and be functional.
I tried earlier to fix Qt5 5.3 Cocoa, and dropped that, since it was way too broken.
Current state of affairs: I got Qt6 built against X11 on Sonoma with minimal patches, only qtbase as of now, and untested whether it is usable. Qt6, because it finally switched to CMake, so at least build system became sane.
With some extra patches the build started on PowerPC, but then got stuck on a bug in handling some CoreFoundation stuff. That code was introduced around 5.8, so even if the earlier version is compilable, we can’t simply revert a couple of breaking commits. I don’t know how bad is that and whether it is the only issue on the way. It is probably not as hopeless as Cocoa, but requires time, effort and a lot of testing.
If you wanna try fixing it, I can make a portfile with w/e I had on 10.6, which will start building (but will fail).
P. S. Re Qt4 and OpenSSL: it seems that MacPorts switched it to OpenSSL 3.x either accidentally (when openssl stub port was switched to that) or at least without much testing. It probably should instead use 1.1.