QMPlay2
QMPlay2 copied to clipboard
zaps166
[macOS] `QMPlay2` 16.04.23 fails to build on 10.6: `OpenGL2Common.hpp: error: 'GLActiveTexture' does not name a type` etc.
@zaps166 This looks like the last release supposed to support Qt4?
:info:build In file included from ./OpenGL2OldWidget.hpp:4,
:info:build from OpenGL2Writer.cpp:7:
:info:build ./OpenGL2Common.hpp: At global scope:
:info:build ./OpenGL2Common.hpp:44:35: error: expected ')' before '*' token
:info:build 44 | typedef void (APIENTRY *GLActiveTexture)(GLenum);
:info:build | ~ ^~
:info:build | )
:info:build ./OpenGL2Common.hpp:45:35: error: expected ')' before '*' token
:info:build 45 | typedef void (APIENTRY *GLGenBuffers)(GLsizei, GLuint *);
:info:build | ~ ^~
:info:build | )
:info:build ./OpenGL2Common.hpp:46:35: error: expected ')' before '*' token
:info:build 46 | typedef void (APIENTRY *GLBindBuffer)(GLenum, GLuint);
:info:build | ~ ^~
:info:build | )
:info:build ./OpenGL2Common.hpp:47:35: error: expected ')' before '*' token
:info:build 47 | typedef void (APIENTRY *GLBufferData)(GLenum, GLsizeiptr, const void *, GLenum);
:info:build | ~ ^~
:info:build | )
:info:build ./OpenGL2Common.hpp:48:35: error: expected ')' before '*' token
:info:build 48 | typedef void (APIENTRY *GLDeleteBuffers)(GLsizei, const GLuint *);
:info:build | ~ ^~
:info:build | )
:info:build ./OpenGL2Common.hpp:84:9: error: 'GLActiveTexture' does not name a type
:info:build 84 | GLActiveTexture glActiveTexture;
:info:build | ^~~~~~~~~~~~~~~
:info:build ./OpenGL2Common.hpp:85:9: error: 'GLGenBuffers' does not name a type
:info:build 85 | GLGenBuffers glGenBuffers;
:info:build | ^~~~~~~~~~~~
:info:build ./OpenGL2Common.hpp:86:9: error: 'GLBindBuffer' does not name a type
:info:build 86 | GLBindBuffer glBindBuffer;
:info:build | ^~~~~~~~~~~~
:info:build ./OpenGL2Common.hpp:87:9: error: 'GLBufferData' does not name a type
:info:build 87 | GLBufferData glBufferData;
:info:build | ^~~~~~~~~~~~
:info:build ./OpenGL2Common.hpp:88:9: error: 'GLDeleteBuffers' does not name a type
:info:build 88 | GLDeleteBuffers glDeleteBuffers;
:info:build | ^~~~~~~~~~~~~~~
Fails both with gcc-4.2 and gcc-13.
Leaving aside FFMpeg incompatibilities with current versions, there are some other errors:
:info:build /opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_multimedia_QMPlay2/QMPlay2/work/compwrap/cxx/opt/local/bin/g++-mp-13 -c -I/opt/local/include -Os -D_GLIBCXX_USE_CXX11_ABI=0 -arch ppc -O2 -arch ppc -Wall -W -DQMPlay2_TagEditor -DQT_NO_DEBUG -DQT_GUI_LIB -DQT_NETWORK_LIB -DQT_CORE_LIB -DQT_SHARED -I/opt/local/libexec/qt4/share/mkspecs/macx-g++ -I. -Ibuild/moc -I/opt/local/libexec/qt4/Library/Frameworks/QtCore.framework/Versions/4/Headers -I/opt/local/libexec/qt4/Library/Frameworks/QtNetwork.framework/Versions/4/Headers -I/opt/local/libexec/qt4/Library/Frameworks/QtGui.framework/Versions/4/Headers -I. -I../qmplay2/headers -I/opt/local/include/taglib -I/opt/local/libexec/qt4/Library/Frameworks/QtGui.framework/Versions/4/Headers -I/opt/local/libexec/qt4/Library/Frameworks/QtNetwork.framework/Versions/4/Headers -I/opt/local/libexec/qt4/Library/Frameworks/QtCore.framework/Versions/4/Headers -I/opt/local/libexec/qt4/include -F/opt/local/libexec/qt4/Library/Frameworks -F/opt/local/libexec/qt4/lib -o build/obj/PlaylistDock.o PlaylistDock.cpp
:info:build MainWidget.cpp: In member function 'void MainWidget::createMenuBar()':
:info:build MainWidget.cpp:697:9: error: 'qt_mac_set_dock_menu' was not declared in this scope
:info:build 697 | qt_mac_set_dock_menu(secondMenu);
:info:build | ^~~~~~~~~~~~~~~~~~~~
:info:build /opt/local/libexec/qt4/include/QtGui/qtransform.h:136:17: note: because 'QTransform' has user-provided 'QTransform& QTransform::operator=(const QTransform&)'
:info:build 136 | QTransform &operator=(const QTransform &);
:info:build | ^~~~~~~~
:info:build PlayClass.cpp: In member function 'void PlayClass::loadSubsFile(const QString&)':
:info:build PlayClass.cpp:327:74: error: 'QRawFont' was not declared in this scope; did you mean 'QFont'?
:info:build 327 | const QString fontName = QRawFont(fontData, 0.0).familyName();
:info:build | ^~~~~~~~
:info:build | QFont
qt_mac_set_dock_menu issue can be fixed with this: https://www.qtcentre.org/threads/13749-Problem-with-QSystemTrayIcon-on-Mac-OS
Then, disabling OpenGL2 and QRawFont, I could make the app compile. Playback does not work, however: possibly, need to properly backport compatibility with modern FFMpeg.
No, I was wrong, this should still build: https://github.com/zaps166/QMPlay2/releases/tag/17.10.24 Or maybe try reverting https://github.com/zaps166/QMPlay2/commit/672f31705d8e16a9114ede0c513dc9fbd1c73348 with a newer version.
Use qt4 branch instead of tag, because it contain a bugfix. It was ~5 years ago, I don't remember, Qt4 is very old.
Also macOS 10.6 is ~15 years old, many things has changed. Recently I improved OpenGL code, but it's for Qt5/Qt6. Try to declare missing types, get from newer headers somehow, maybe it'll work (or add possibly missing GL includes).
@zaps166 Thank you, I will try.
Use qt4 branch instead of tag
I actually tried already, but turned out it still forces Qt5 (Qt5MacExtras and non-existing with Qt4 headers in a few spots), but that it fixable.
Basically I need to revert everything which breaks Qt4, but backport support for FFMpeg 4.x+. Looks doable, but perhaps already not tonight. (Nothing reverts or cherry-picks cleanly, so while perhaps most of that will be mechanical, it likely gonna take some time.)
I don't remember, but maybe I always used Qt5 for macOS builds. You can disable everything which needs Qt5MacExtras.
@zaps166 I actually got it working on PowerPC with Qt4. (And on Sonoma with Qt5, but that is no big deal.)
Took infinite number of rebuilds and quite substantial patching for Qt4 case, but I can play the videos now. Did not test further, need some sleep :)
If you will have a bit of time to look through and suggest improvements, it would be awesome. This branch has a set of patches which fix the build and apparently make the app functional: https://github.com/barracuda156/QMPlay2/tree/qt4-rev2 I had to revert a number of commits which did not build. Quite possibly reverting is suboptimal, and I just did not know how to backport the new code to Qt4. (There is also an issue with SDK: Obj C stuff is unlikely to work on older systems, and something will be missing in system headers. However aside of Obj C things can be backported, perhaps.)
Most of the problematic code is from 17.x branch (which is also present in Qt4 branch). The last 16.x release built rather neatly with minimal patching, as I mention above.
If you have Macports, this should build: https://github.com/macports/macports-ports/commit/7a76ba20a98d8a7cca754b78e60ebb205cf6c39d Or if that is rebased, branch: https://github.com/barracuda156/macports-ports/tree/QMPlay2
P. S. Most of multimedia players are broken on old macOS (primary issue are bugs in X11 and SDL2, which prevent them from working correctly, especially on Big-endian platforms; for instance, I could fix the build of VLC2 eventually, but colors are wrong with X11 output, while SDL is just broken). It was great to find your project – which looks a very promising option, as of now.
@zaps166 A quick update: video seems to work fine, though with 4K PowerPC machine is really struggling. Menus pretty much all work, scrolling via scrolling works, via clicking on scroll bars does not.
Youtube browsing seems dead on Qt4 version, but works on Qt5 one. (Can we backport a fix for it?)
Anime browsing is dead on Qt4 and missing on Qt5.
Later on the rest.
@zaps166 Could you say if this https://github.com/zaps166/QMPlay2/commit/c8fb2b0c20ff4fe0fd7ffdf210985b3fc7f18afa is portable to Qt4 or not? (I am not asking you to port it, to be clear. I just wanna know if it is feasible.)
For the context: I wanna try fixing YouTube and Mediabrowser, which are broken in Qt4-based version.
UPD. It might, possibly, via https://github.com/eteran/qjson4
UPD2. It looks like QJson4 in fact works. What does not work is QLoggingCategory, I have to drop backporting that part, I guess.
@zaps166 Thank you. Maybe you have a guess why YouTube search does not work with Qt4 version?
If we know the likely cause, I can try backporting specific patches rather than blindly trying to backport everything that touched YouTube module (and then dropping some chunks, since not everything gonna build or link).
(I sort of did backport a large part of later changes, but the build erred out on YouTube.cpp, likely due to what you point out – scripts behave differently, even though some of Qt5 code can work via Qtjson4 library.)
I added support for QMPlay2 into SMtube today (in Macports, not upstream), and it works for playback of YouTube vids beautifully. But it would be more logical and user-friendly just to make internal YouTube module of QMPlay2 work (for Qt4; with Qt5 it does work perfectly as-is).
This software is for Qt 5.10 and above :smile:
What "YouTube search does not work with Qt4 version" does mean? Doesn't compile? Maybe you did something wrong with porting, it uses custom networking class which uses FFmpeg + maybe you need to do something with JSON lib for Qt4.
The old code in qt4 branch is obsolete and might not be compatible with youtube anymore.
@zaps166 Yes, I have been referring to your Qt4 branch :)
Everything builds fine, and video playback works with no issues, but everything online-search related does not work. Modules are built, but if I try inputting a keyword to search for whatever on Youtube, no output is produced, it remains blank.
I just built it on 10.6.8 x86_64 (so the issue is not PowerPC-specific at least):
(It reports version 17.10.24.)
With backporting, it is pretty likely I got something wrong or trivially incomplete, but perhaps to make Youtube search working we do not need to backport everything committed for related module ever since. I just have no idea what prevents it from working. I could try to do incremental backporting with rebuilds per-commit to see if any change occurs.
The old branch is obsolete and search doesn't work because of YouTube website changes. You need to port most QMPlay2's youtube patches to make it work correctly.
@zaps166 Just for the reference, this is not abandoned, but will take some time. (No need to re-open the issue, of course. If I get it to work with YouTube, I will update here.)
Ok, but I closed it because it's no longer supported. Btw. do you want to create a PR to qt4 branch?
@zaps166 If you will accept it, sure, I will.
I will need some time though, since I am on a trip at the moment and only have arm64 laptop, where Qt4 does not even build. I gonna try sorting out back ports of some later commits in the meanwhile (which has to be done anyway prior to testing to see what can be built with Qt4 and whether that gonna improve the app), and once I am back to my PowerPC and x86 hardware, gonna test everything.
It will be nice to have some online capabilities working, though at the moment I have no idea if that could work in principle with the old Qt4. But I will try to fix at least something. QMPlay2 is a great app, and as of now, I think, the only player with GUI in Macports which works perfectly for video-playback on PowerPC. (I kinda have WIP to fix VLC2, but I could only make X11 backend to work so far, and that one has some endianness?-related bug, which I had no time to track down.)
@barracuda156 was it you who thought he might use my patches to build Qt5 in X11/XCB mode to port Qt5 to PowerPC?
QMPlay2 is currently Qt 5.10+ as pointed out above, but you may have seen that I have a patch to make it build against Qt 5.9 . If ever there was a Qt5 version that supported the platforms you are targetting you will probably do good to get a more current QMPlay2 version to build against that Qt5 version. That could be a tall order too, but you'd mostly be implementing relatively simple glue/conditional code or algorithms rather than trying to understand the inner QMPlay2 workings.
@RJVB Yeah, it was me, we discussed it briefly here: https://trac.macports.org/ticket/69051 I did not have time to return to that so far. (Well, it demotivates also when you spend hours on something and it keeps getting nowhere. Qt upstream did a “good job” breaking everything in a versatile way, LOL.)
On Monday March 18 2024 14:27:26 Sergey Fedorov wrote:
Well, it demotivates also when you spend hours on something and it keeps getting nowhere.
Would that be a rabbit or a black hole? :) I had one recently where I spent a considerable amount of time on getting a newer webkit2-gtk to build, only to find out that it made my system KP.
Qt upstream did a “good job” breaking everything in a versatile way, LOL.)
That's why I'm really not looking forward to the day I cave and upgrade my Mac, after which I'll "have" to upgrade my Qt5 port too...
@catap has been doing some work to fix webkit2-gtk, AFAIK. Not sure what is the current state of the issue.
On Mon, 18 Mar 2024 23:53:50 +0100, Sergey Fedorov wrote:
@catap has been doing some work to fix
webkit2-gtk, AFAIK. Not sure what is the current state of the issue.
I buuild it, but it crashes on any attempt to use it.
-- wbr, Kirill
I buuild it, but it crashes on any attempt to use it.
What version? The app crashing is better than it crashing the entire machine (the 2nd time it didn't even KP immediately, but the morning after when I had almost forgotten that I had used it once...)
(And FWIW, I built the same version on Linux, where it runs fine with its own MiniBrowser but just "beachballs" in Epiphany, so maybe I need to upgrade that one too.)
I buuild it, but it crashes on any attempt to use it. What version? The app crashing is better than it crashing the entire machine (the 2nd time it didn't even KP immediately, but the morning after when I had almost forgotten that I had used it once...) (And FWIW, I built the same version on Linux, where it runs fine with its own MiniBrowser but just "beachballs" in Epiphany, so maybe I need to upgrade that one too.)
I mean crashing an example from webkit, I haven't tried to move forward. The status available here: https://github.com/catap/macports-ports/tree/webkit2-gtk-devel
I mean crashing an example from webkit
That's the thing: the MiniBrowser appears to work in my build (except for about:gpu which is probably because I had to disable the entire WEB_GL feature), but it then causes an instability somewhere that leads to a KP ultimately. It reminded me of how I used to have those with earlier OS X versions when I was still actively doing OpenGL programming myself.
@mascguy is also working on updating webkit2-gtk-devel; my version was based on his, hence: https://github.com/mascguy/macports-ports/pull/1
A few weeks back I read a discussion on the LLVM discourse pages that mentioned how clang versions before 17 had broken support for C++20 that could also lead to miscompiles. WK 2.40 requires that standard but I had been using clang-12 and indeed encountered a number of seemingly illogical build failures (that I avoided by disabling WEBGL). According to that LLVM discussion you'd have to use GCC12+ or clang-17 (which can't even build itself at the moment; probably because it needs to have a more recent libc++ runtime that we currently have in MacPorts). I haven't yet had the courage to try again now that I have GCC12 because my experience with the newer WK version on Linux shows too little gain w.r.t. 2.28.2 (but a lot more hunger for resources).