Question/suggestion: Qt as a static library (dependent component license restrictions) #11
Comments
|
As an example, this little game (available on Ubuntu) is released under MIT license: The least thing I want in life is to stick GPL to it. |
|
I don't have a ton of knowledge on licenses, but I've been building Qt shared for Otter personally. Didn't know MXE did it static. BTW, MESA (libgallium_wgl) crashes on Windows 10RT (15035). I know it isn't related to this, but I thought I would let you know. |
|
Switching to shared works perfectly fine for me though. |
I have a Win10RT build on Lumia 640XL, will be able to do rough troubleshooting. Guess should also install on it on a Surface to have a compatible testing environment. Ambulance envvars: https://docs.mesa3d.org/envvars.html |
|
or |
|
I've used softpipe on my Surface, it is PAINFULLY slow. That's why I switched to ANGLE for Qt. |
Oh, cool, so it's not the intrastructure failing us, but D3D itself. Then just the first two envvars. |
|
BTW how did you provide DX SDK to ANGLE? Some cmake flag? A path in the PATH var? |
|
I didn't. I just used vcpkg with LLVM-MinGW. You set it up like normal on Linux, but with MXE/LLVM-MinGW in your path, then you build with |
|
It required some... strange fixes to build Qt though. Namely that a few defines were missing, had to explicitly define that we were using ANGLE/GLES2 in C++ files, etc. I can send the defines fix, it just needs added to the end of I know it's a messy fix, but I'm still very inexperienced, especially at my age. |
|
Ack. Will further look into that, too. |
|
Could never get it to build with that due to random failed tests, so I just went with Google's (/vcpkg's) plain ANGLE. |
|
First successful build of Installed 15035 on a Surface 2 for regression testing. (If 9600 is Rita, then 1535 is Lima, for the year Peru's capital was founded?) |
|
Lima sounds good. Also, yeh, I forgot about DX12 in Qt. Give me a minute and I'll send you the configuration lines I used 👍 |
|
Here ya go. QtActiveQt and QtQuick3D was broken from OG source, so I disabled them. As for WMF, DirectShow crashes on 15035 (Surface 2) and like said... I didn't (and am not really sure still) how to debug it. |
That was the flag! I simulated a failed D3D12 test by patching out a D3D12
Will take a look. Have both setups (9600 and 15035) now. |
|
Awesome! I'll look into how to debug, if you could say what app I should use (or even the steps 😩), that'd be really helpful. (And the platform without |
|
(I have been using WinDbg with no luck) |
|
Installed the 15035 build. Built 2048-Qt as a test app. Did a preliminary troubleshooting w/ WinDBG in Qt apps (as opposed to Qt libraries) fit naturally in %DISTRO_ROOT%/Qt5. Any other location needs a OG image: 2048-Qt running in software. |
|
That crash is likely MESA/Qt's ANGLE. If you look at the latest Otter build, it uses ANGLE built from vcpkg and runs perfectly fine, even using WebGL on sites available with it. I could only test it on 15035 however. I don't have a dual boot setup going yet on my Surface. I do vaguely remember that null pointer error and it was fixable and related to something with a flag in the MESA build IIRC? Like |
|
OK I should probably rephrase "fine". It crashes on a lot of sites but WebGL/ANGLE works fine 😂😂😂. |
|
Fair enough. Looks like ANGLE would be better off as a separate component providing EGL/OpenGLES, with MESA kept as a software fallback (and a d3d12 playground)? Then Qt (built in shared mode) would link with ANGLE (also built in shared mode) via ANGLE_DIR. I have yet to see if the Qt-ANGLE-DirectShow video codec integration stays functional that way, but I expect it would. DLLs providing OpenGL need to have different sonames (same as w/ Qt building "combined ANGLE"), and ANGLE should be the default (this deviates from "combined ANGLE"); also, keeping Qt as the ANGLE provider would introduce unnecessary package dependencies. So, OK, extracting a
Symlinked (and qt.conf isn't much different from a Unix symlink). Or 32G devices will quickly run out of space. No dual boot here either, just a box of used RT and RT2 tablets. |
ANGLE would likely be our best bet for ALL Qt OpenGL related stuff, EGL/OGLES/WebGL/etc. I don't know if using MESA as a software fallback would be functional at all given how horrendously slow softpipe is on the Surface devices (no clue about Lumia/etc), but it could be good as a D3D12 playground I suppose. ANGLE runs pretty good on the Surface devices though, apparently. I just forced it to link by using
I don't know anything about what Qt outputs, I used vcpkg's ANGLE DLLs/libs only since I didn't want to even mess with Qt's ANGLE.
Okay, true.
Oh, I see. I only own one Surface device and no other ARM tablets 😢. I want more, but I do not have a job yet. May get a VM running for 15035 and get 9600 back on my Surface as a dual boot.
I could have sworn the UCRT files are from the 10 SDK, wouldn't that make them automatically need signed (or am I wrong)? |
They do have a signature, and it's expired. Enough for 9600 to complain. I self-signed a certificate backdated to 2011 and expiring by 2221, that one works. |
|
Interesting. I just never auto-signed myself 😂 |
|
PowerShell (admin): (will display some hash, like ABCDABCDEFEFEFEFABCDABCDEFEFEFEF01230123) Then it's possible to use signtool from WSL like this: The current directory should be that of the file being signed, so pushd/popd. |
|
P.S. The Ubuntu for signtool is (expected to be) Mono signcode but Windows can't recognize the signature it generates. |
|
I see. I barely ever use Windows, anything I do in it is now from a VM (thanks Win11 for breaking BCD and winload after a single restart!) cause of how horribly unstable and bad it is. I'll do any signing on my Surface, I can not bear normal Windows.
|
|
Well, thanks again for maintaining this toolchain and repo then! Really altruistic of you. |
|
Crazy weird. GLES2 shouldn't reference EGL types. |
|
|
|
From the Is this the case for you, particularly the first typedef? |
|
With line numbers: |
|
This is my Python environment: |
|
|
Would be helpful to see yours, and also the contents of your target |
|
Let me rebuild everything real quick, I'm on my laptop |
|
Before I do this though, the |
Because
|
|
Ohhh. I see. |
|
Interesting. On my laptop, it can not even configure.
|
|
zlib wasn't found. We should proooobably add zlib to the |
Host or target? On the target it uses (is expected to use) |
|
Target. CMake looks for the other zlib still, causing the error. |
|
Then the right fix would be pointing CMake to its |
|
For now, let's see what's different about the |
|
Right. Once this build completes, I'll send logs of all of the things that you sent. |
|
grep without lines: grep with lines: Python environment: pip3 list: |
|
The typedef is there. Does the sample still fail to build? |
|
No, but because that sed command is there 😂. Let me remove it. |
|
By the way, should we move this into a separate issue? |
|
Sure. |
|
Alright. Am I creating it or you? By the way, the build works fine on my laptop. Desktop seems to be the culprit of issues... But I can't imagine why. The build environment is the exact same. |
|
Forked 3 outstanding issues. This one can be closed I think. |
|
Got it. Thanks. We'll re-open if needbe. |
If Qt is compiled as a static library, it can only be used by GPL-licensed components (static linkage produces a "derivative work", while dynamic merely constitutes "use"). Not a big issue as long as we have no [non-GPL, or any, for that matter] Qt apps in the repo, but we may want to (and users may want, too).
I would suggest switching Qt artifact build mode from static to shared. If it's unacceptable for any reason, we should put a heads up note somewhere in the documentation. (I understand the issue isn't introduced here but rather is common w/ mxe/mxe, but Intel builds worry me much less, TBH.)
E-mailed w/ more details. /* Currently injecting DX SDK into the declarative plugin, stay tuned. */
The text was updated successfully, but these errors were encountered: