thp
commented
2 months ago Have you checked if the fork at https://github.com/thp/linux-minidisc works any better? See PR #85.
Open barracuda156 opened 2 months ago
thp
commented
2 months ago Have you checked if the fork at https://github.com/thp/linux-minidisc works any better? See PR #85.
barracuda156
commented
2 months ago Provided Qt4 is supported in that branch, I can try building it.
thp
commented
2 months ago Have you checked looking into porting newer versions of Qt 5 / Qt 6 to PowerPC? Qt 5 is already "old" now in 2024, having a port of Qt 5 to PowerPC will make sure you can more easily port upstream projects that require Qt 5 without having to require all upstream projects to drag along Qt 4 support forever (but that obviously is just my personal opinion :).
barracuda156
commented
2 months ago Have you checked looking into porting newer versions of Qt 5 / Qt 6 to PowerPC? Qt 5 is already "old" now in 2024, having a port of Qt 5 to PowerPC will make sure you can more easily port upstream projects that require Qt 5 without having to require all upstream projects to drag along Qt 4 support forever (but that obviously is just my personal opinion :).
I did. The issue is that it is written in a way to hardcode Cocoa backend on MacOS. What we need for this to work is X11. Now, X11 backend is broken on MacOS across the board, on Sonoma as well, not just ppc. I had provisionally fixed the build of qt6-qtbase with X11 backend on 14.6, but it is untested. I made some build system fix-ups so that it starts to build on powerpc, but then it fails on some obscure MacOS SDK-related issue. Reverting to an earlier version of that specific code part does not work, since it dates back to Qt 5.8. So now it is needed to figure out what is exactly broken and how to re-implement it. Even it is accomplished (and assuming the thing actually works and not just builds and segfaults), qtbase on its own is not enough for anything, So the same should be done for a few other components to have some minimally useful Qt6. (I say Qt6 because I do not want to deal with retarded build system of Qt5; Qt6 thankfully switched to using CMake.)
Having this in mind, I do not even know how much time it gonna take to fix Qt code for the modern macOS.
thp
commented
2 months ago Having this in mind, I do not even know how much time it gonna take to fix Qt code for the modern macOS.
The fork linked above works fine with Qt 5.15.13 (using the Cocoa backend -- I guess you meant X11, which I didn't test here) from Homebrew in macOS 14.6.1:
barracuda156
commented
2 months ago Having this in mind, I do not even know how much time it gonna take to fix Qt code for the modern macOS.
The fork linked above works fine with Qt 5.15.13 (using the Cocoa backend -- I guess you meant X11
Yeah, I meant Qt itself with X11. That is broken, so nothing of dependents can be built by implication.
I will try meson branch with Qt4; assuming major changes were to the build system, that should work, since this repo code builds with Qt4.
barracuda156
commented
2 months ago @thp Could you say if Qt4 support was pro-actively removed in the sources or it is just meson sets Qt5 as the only option arbitrarily? I looked through commit history in your repo a bit, but there are a lot.
P. S. I cannot recall a port using meson with Qt4, but CMake handles it with no issues. If it is only the build system, perhaps it can work. I am not planning to do any huge rewriting, no time for that.
thp
commented
2 months ago @thp Could you say if Qt4 support was pro-actively removed in the sources or it is just
mesonsets Qt5 as the only option arbitrarily? I looked through commit history in your repo a bit, but there are a lot.
I only tested on Qt 5, as Qt 4 was already not really supported in 2022 when I did the changes.
Launching the app fails:
gdbshows this: