qt5.x on PowerPC: approaches to bypass broken Cocoa

[barracuda156]

I made some attempts to fix early qt5 (qtbase) versions on PowerPC, and after sorting out what upstream has broken with build system itself plus some minor bugs I bumped into failures with Cocoa code (unsurprisingly so, to be honest).

Now, the problem is that Cocoa was already broken in qt4, and Macports builds qt4 as Carbon (which works nicely). However, Carbon was thrown away with qt5 release, as well as support for Leopard.

Given that it never worked to begin with, it is perhaps completely unrealistic to have it fixed in any version of Qt5, and arguably a waste of time to even try. What seems at least possible in principle are the following:

1. Turn off Mac-specific stuff in .pro files which include respective directories and use generic Unix code. (Trivial effort, might work?)
2. Build with whatever Mac-specific code is there, but use ad hoc fixes like it was done for SDL2 at some point. (Likely high effort, perhaps will end up defunct.)
3. Restore Carbon code which was known to work fine. Caveat: if the design is not really modular and substantial amount of generic code refers to specific Cocoa functions, that will not work. If the task pretty much amounts to tracking down which chunks of code should go where and then copying those from 4.8.7 with some minor amendments, that should be doable with reasonable efforts: Qt4 has about 100 files which have fallbacks to Carbon and perhaps something like 400 instances of fallback code chunks altogether. Tracking down is itself a problematic task, since the codebase structure had been changed substantially, but it should be feasible.

Perhaps aside of Cocoa stuff nothing in Qt5 is too broken and should build with minimal fixups.

What do you think? What sounds more reasonable?

[RJVB (René Bertin)]

I'd start with 1) with an attempt at 2) for features where the generic code is more or less dummy code. If that leads to something more or less workable you can try to use 3) for the most sorely missing features.

I've done quite a bit of 1) in my qt5-kde-x11 effort and most of that was just figuring out the build system, plus remembering that OS X is more akin to BSD than to Linux in many cases.

Is there still *any* PowerPC-specific code in Qt5, for *n?x OSes running on that architecture? If not you'll likely end up with something that's pretty slow... You might want to find a recent PPC Linux for your Powermac and set up a test environment to see how happy you are with Qt5 apps there, before spending a lot of effort!

(Actually, if I still had a working PPC Mac I'd probably be running it under Linux or *BSD by now, if not just using it for the stuff it can still do with its original software!)

[barracuda156]

Replying to RJVB:

I'd start with 1) with an attempt at 2) for features where the generic code is more or less dummy code. If that leads to something more or less workable you can try to use 3) for the most sorely missing features.

I've done quite a bit of 1) in my qt5-kde-x11 effort and most of that was just figuring out the build system, plus remembering that OS X is more akin to BSD than to Linux in many cases.

Is there still *any* PowerPC-specific code in Qt5, for *n?x OSes running on that architecture? If not you'll likely end up with something that's pretty slow... You might want to find a recent PPC Linux for your Powermac and set up a test environment to see how happy you are with Qt5 apps there, before spending a lot of effort!

(Actually, if I still had a working PPC Mac I'd probably be running it under Linux or *BSD by now, if not just using it for the stuff it can still do with its original software!)

I would be genuinely surprised if Qt5 is broken on Linux and BSD PowerPC; while it is not an architecture of primary support, AFAIK it is totally usable, and if I am not wrong Ken mentioned he has Qt5 working on Debian on his PowerMacs.

Personally I am not greatly concerned about the speed here, since apps I am interested in are not computationally intensive, they just have no support for Qt4, or it is archaic, and having wasted hours on fixing fallback versions I started thinking that fixing some Qt5 will be easier in result. (I do not expect to end up with fully-functional 5.15, to be honest.)

[RJVB (René Bertin)]

I don't think I implied that Qt5 would be broken on PPC Linux or *BSD?

But FWIW, Qt5 uses a lot of hardware acceleration (SSE and the like) for common operations, including on strings. I never tried to build it without so I have no idea how much of a penalty that would incur but I'm pretty certain it was significant enough that resources were invested in it.

Anyway, it's up to you of course, but me I'd be investing my time in setting up dual-boot and getting a nice DE running under a more modern OS where I could use "apps I'm interested in" without further investment.

[kencu (Ken)]

qt5 (latest) and qt6 (current) run nicely on debian 12 PPC.

[barracuda156]

Replying to RJVB:

I don't think I implied that Qt5 would be broken on PPC Linux or *BSD?

It is not broken on BSD, but qt5-webengine is broken.