Qt apps do not respect QT_ANGLE_PLATFORM #15
Comments
|
Would look into this, but I can't get Qt to even configure and build qmake? Seems to be something to do with GCC, but I don't know how to check or fix it or even use Clang for this for that matter. Log: |
|
If you retry the offending |
|
Where would I find the STL headers? (I'm not sure which ones those are 😅) |
|
Found the issue. |
|
Files that need it: All of the Qt core components are on this organization too, in case something like this ever came up and we didn't want to use the patch files (or it'd be simply inefficient) |
|
Now another Qt issue --
|
I vaguely remember tuning it up -- there was a discrepancy between liblibsomething.a and libsomething.dll.a |
|
I'd say maybe we could use sed and just change lib/liblibGLESv2 and lib/liblibEGL to -lEGL and -lGLESv2 in the Makefile but that'd require every Makefile to be edited |
|
There was a one-place fix. I am not on the dev machine right now but I'll dig it up later today I think. |
|
Like symlinking the files after building ANGLE (or any EGL/OpenGLES provider, for that matter). |
|
Alright, sounds good. Just wanted to let you know about the include files being needed in those 4 files and the liblibGLESv2/liblibEGL issue if you hadn't seen yet. |
|
Ack. |
|
Atleast the include files are a simple fix. Add |
|
Update: qtbase successfully builds with the liblibEGL/liblibGLESv2 in place and those 4 include files fixed. So nothing huge needed to fix for MXE.
|
|
Update 2: Anything built afterwards tries to rely on liblibEGL/liblibGLESv2 in armv7-w64-mingw32/qt5/lib/*. What a strange bug 😂
|
|
Update 3: Added a patch for the include files. It's here if you wanna see it. |
|
Oh, and the liblibEGL/liblibGLESv2 errors are gone after a re-build. Guess it just failed to create a link to the actual files the first time I built. |
|
Update 4: Added bthprops.lib to the resources and just linked to it in the Makefile. Just did this for people who aren't on WSL/are on pure Linux (AKA me :)). |
Not perfect license-wise, but since *.lib is merely a list of exported symbols, probably OK. |
|
I'm still a bit unfamiliar with licenses. My bad 😅 |
|
How come it's needed in qtconnectivity, anywho? I never needed it in my old builds |
|
It needs some bluetooth API. If there are API headers/exports in mxe that can be used, we may want to choose them instead. As of old builds -- did any real (user-facing) package ever depend on qtconnectivity? |
|
Not that I noticed. Unless WebKit needed it. I don't remember. I can try and look through my old packages and see if you want. |
|
Okay... That's probably why none of my builds needed it. It just builds without it and I never realized 😂
|
|
Anyway, everything after seems to be stable/on a good track. Kind of insane how little was actually needed to port base Qt to such a platform.
|
|
Update 5: It's built! qttools has a slight issue. Did a sloppy fix, but I'm not going to push it since we can probably just fix it entirely. It fails to configure the test, due to Qt5UiTools.prl.
Notable error: What I did to fix it: Delete Qt5UiTools.prl. Builds the test fine without it. |
|
Looks like the issue is double plus -- plus by itself is a special sign in PCRE.
Should be: "^stdc\+\+(\.lib)?$" (both plus characters escaped).
|
|
Thing is, I've looked at the file. Can't find anything about "^stdc++(\.lib)?$". Maybe I overlooked. I'll look again. |
|
It's all codegen over codegen over codegen... Worst case if cmake files are generated directly by qmake w/o any template. |
|
Yeah, but I don't use it. |
|
I was able to also get sed to work as a fix. Just replaced libstdc++ with EGL. Seems to only be that "-lstdc++" string in the prl file causing issues.
|
|
Nevermind, take that back. I suck at sed, that just makes the file empty 😂 |
|
OK, so sitting the qttools issue aside, I've finally got Qt sitting on my Surface, and of course... It doesn't respect QT_ANGLE_PLATFORM at all 😂. Expected it, though. |
|
Been looking into this and around for the file that contains how it's handled Any possibility you know where it could be (or what module of Qt it would be in)? |
|
Hate to say it, but it actually looks like ANGLE is the victim here. Was playing around and built SM64 again with GLES for fun, and saw that it ONLY tries D3D11 and D3D9 is essentially not there to it ("no available renderers"). Using ANGLE built from MSVC doesn't crash the game and no errors are sputted out by ANGLE. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Right now I am troubleshooting renderer choice by Qt.
My present inference is that
QT_ANGLE_PLATFORMis read and processed by the ANGLE version bundled in Qt rather than its Qt client code. As a result, Qt sticks with d3d11 and fails.I can polish my branch until Qt widgets work properly, or we can merge it as is (since ANGLE is already good and has a working sample). You can try consuming ANGLE from other components to see what works and what's broken.
ANGLE offers access to accelerated video playback. I was going to look at this after 3D graphics is good.
Originally posted by @treeswift in #11 (comment)
The text was updated successfully, but these errors were encountered: