VCPKG Qt6 builds with MSVC 2022 - PyQGIS.api.rule not able to load Qt plugins

[danodom-tcb]

What is the bug or the crash?

Not sure what the issue is here, or what's missing.

I am trying to build on Visual Studio 2022 on Windows 11. I am using the VCPKG install instructions that were updated recently in the Install.md file.

Steps to reproduce the issue

Run a full build of the QGIS solution that was generated in using the vcpkg instructions.

Versions

latest version of master

Supported QGIS version

• [X] I'm running a supported QGIS version according to the roadmap.

New profile

• [ ] I tried with a new QGIS profile

Additional context

No response

[danodom-tcb]

I did go try and build the pygqis-pap project and received the following message :

I am not sure what this means or how to resolve this.

[danodom-tcb]

I found this on StackOverflow for the same issue with something else, and doing this did not resolve the issue. Any thoughts on this?

Also, I could only find the bin and plugins folder for Qt5 not Qt6.

[danodom-tcb]

@jef-n @m-kuhn do either of you have any suggestions here? I know that @jef-n updated the windows documentation about a week ago and hoping one of you know how to resolve this.

[m-kuhn]

@danodom-tcb I am not sure exactly, what is causing this. Can you try to build with -DWIDTH_QSCIAPI=OFF, it might be easiest to disable this for now?

Further notes:

• You are building with Qt6 I assume (did you pass BUILD_WITH_QT6=ON / do you see this in your CMakeCache.txt file)
• Could you please paste links and text instead of screenshots where possible?

[danodom-tcb]

@danodom-tcb I am not sure exactly, what is causing this. Can you try to build with -DWIDTH_QSCIAPI=OFF, it might be easiest to disable this for now?

Further notes:

• You are building with Qt6 I assume (did you pass BUILD_WITH_QT6=ON / do you see this in your CMakeCache.txt file)

• Could you please paste links and text instead of screenshots where possible?

• Could you please paste links and text instead of screenshots where possible? Sure thing, I was thinking the visual may help, but can pivot.

• You are building with Qt6 I assume (did you pass BUILD_WITH_QT6=ON / do you see this in your CMakeCache.txt file) I am building with whatever the defaults are set to that were generated in the cmake process that builds out the Visual Studio solution.

This is set in the root Cmake : __set (BUILD_WITHQT6 FALSE CACHE BOOL "Enable (experimental) Qt6 support") I don't see anywhere where this is altered, so assume it is false._

Regarding the WIDTHQSCIAPI, in the root Cmake as well : # concatenate QScintilla2 API files if (WITH_GUI) set (WITH_QSCIAPI TRUE CACHE BOOL "Whether to generate PyQGIS QScintilla2 API file. (For devs) run 'make qsci-pap-src' in between QGIS build and install to regenerate .pap file in source tree for console auto-completion.")

keep casual users from updating their source tree via WITH_QSCIAPI

  mark_as_advanced (WITH_QSCIAPI)
endif()_

Also, if not obvious, I am new to QGIS, and fairly new to Python as well, but have someone I am leveraging to assist as well. Just for some perspective.

@danodom-tcb I am not sure exactly, what is causing this. Can you try to build with -DWIDTH_QSCIAPI=OFF, it might be easiest to disable this for now?

@m-kuhn, if you think this will resolve the issue, I can force this to false in the CMake and rebuild. The rebuild takes 3-4 hours, which seems a bit high, and I have decent resources on the server I am using.

[m-kuhn]

check your CMakeCache.txt file for the actual value, cmake vars are adjusted via cmake calls (the ones from the INSTALL file) and persisted in this cache

[m-kuhn]

@danodom-tcb I am not sure exactly, what is causing this. Can you try to build with -DWIDTH_QSCIAPI=OFF, it might be easiest to disable this for now?

@m-kuhn, if you think this will resolve the issue, I can force this to false in the CMake and rebuild. The rebuild takes 3-4 hours, which seems a bit high, and I have decent resources on the server I am using.

It should only trigger a partial rebuild if nothing else is changed

[danodom-tcb]

check your CMakeCache.txt file for the actual value, cmake vars are adjusted via cmake calls (the ones from the INSTALL file) and persisted in this cache

Attached.. and I am also getting back into the CMake world and it's changed a lot since I did this way back in the day and haven't been in this world in a long time... (see attached)

CMakeCache.txt

[danodom-tcb]

@danodom-tcb I am not sure exactly, what is causing this. Can you try to build with -DWIDTH_QSCIAPI=OFF, it might be easiest to disable this for now?

@m-kuhn, if you think this will resolve the issue, I can force this to false in the CMake and rebuild. The rebuild takes 3-4 hours, which seems a bit high, and I have decent resources on the server I am using.

It should only trigger a partial rebuild if nothing else is changed it may be a partial build in a lot of cases, but the comment I put in yesterday triggered a full rebuild.

@m-kuhn , which parameter(s) would you recommend that I tweak/adjust in the CMakeCache.txt?

[danodom-tcb]

@danodom-tcb I am not sure exactly, what is causing this. Can you try to build with -DWIDTH_QSCIAPI=OFF, it might be easiest to disable this for now?

@m-kuhn, if you think this will resolve the issue, I can force this to false in the CMake and rebuild. The rebuild takes 3-4 hours, which seems a bit high, and I have decent resources on the server I am using.

It should only trigger a partial rebuild if nothing else is changed it may be a partial build in a lot of cases, but the comment I put in yesterday triggered a full rebuild.

@m-kuhn , which parameter(s) would you recommend that I tweak/adjust in the CMakeCache.txt?

I tried turning off "WITH_QSCIAPI" by setting to false in the Cache file, but it failed pretty much immediately in the same manner, as I assume that the TRUE is probably cached somewhere. What do I need to rebuild to pick this up?

[m-kuhn]

I can see in there that BUILD_WITH_QT6=ON, so you are definitely building with Qt6. As expected. If you rerun cmake to adjust the param cmake -DWIDTH_QSCIAPI=OFF [yourbuildfolderhere], this will adjust the CMakeCache.txt file (you don't normally do that manually) and also regenerate your vs solution in place. This does not necessarily require a full rebuild after (vs is quite good in knowing what is still valid from the last compiler run).

[danodom-tcb]

@m-kuhn so, it looks like it built, but when I went to run it, it threw the same error as above when running the exe.

Is there a trick to running this? I would assume that running the .exe would work.. The date/time stamps may be ok based on the fact that it didn't rebuild everything. But I could be looking in the wrong place.

[m-kuhn]

strange, is there any way in vs to disable this pyqgis-pap target? it's not required at all.

[danodom-tcb]

strange, is there any way in vs to disable this pyqgis-pap target? it's not required at all.

I can remove it from the project dependencies for the solution as long as nothing depends on that project.

[m-kuhn]

I would do that as a workaround for you right now. I'll rename this and leave it open for a future fix.

[danodom-tcb]

I would do that as a workaround for you right now. I'll rename this and leave it open for a future fix.

I guess when I did the cmake command above, it removed that project as a dependency, so it is not in the dependency list now and removed from the solution.

are there any other artifacts, or maybe other things that were compiled with that value being TRUE and expecting it to be there?

[m-kuhn]

compile ahead and report if there are issues.

[danodom-tcb]

compile ahead and report if there are issues.

This is in the CMakeLists.txt file in the python folder, so I assume that this value is applicable to all python projects?

I'll just do a rebuild and see where it gets us.

Again, thanks for your help, wouldn't be this far without your assistance.

[danodom-tcb]

compile ahead and report if there are issues.

Same issue with the "This application failed to start because no Qt platform plugin could be initialized" error.

This was a full rebuild of everything.

[m-kuhn]

In which target? You mentioned the previous one was removed (https://github.com/qgis/QGIS/issues/59173#issuecomment-2432803079)

[danodom-tcb]

In which target? You mentioned the previous one was removed (#59173 (comment))

Also, I didn't actually remove it manually, when I ran that CMAKE command to update the settings in the cache, it was removed from the solution, so I assume there was something in that process that did that as I didn't touch it.

Release target. this is the same error I was getting on the build until we turned off the WITH_QSCIAPI in the settings cache file.

Is there something in the build artifacts (existing or not) that could help give a clue?

[danodom-tcb]

@m-kuhn would there be anything in the cache settings? I am guessing that this is something python related, and some sort of dependencies or maybe something I don't have installed, but not sure which.

Also, I noticed on a a system I used the installer for QGIS and there is a corresponding env file that I don't see in the build artifacts. Not sure if that is part of the problem or not, but wanted to note it.

[danodom-tcb]

@m-kuhn this kind of feels like there's something missing from the SDK that's referenced. I looked at the prior version and it's pointing to Qt5 and there are a number of other components referenced. for Qt6, it looks like maybe the structure of what's in the SDK changed, but maybe the references didn't

Will the latest version work on Qt5? if so, how would be the best way to get the build pointing at Qt5, with the cache settings etc.?

[m-kuhn]

If you build using these instructions, everything will be with qt6. In general it will be easier to assist if we have build logs. If you can build from command line (see https://github.com/qgis/QGIS/blob/master/INSTALL.md#4321-build-with-an-sdk) and copy paste the output to gist.github.com and share it here, this would nake things easier.

P.S. Don't point the build to other external components like qt5, python other other libraries. This shouldn't be required.

[danodom-tcb]

If you build using these instructions, everything will be with qt6. In general it will be easier to assist if we have build logs. If you can build from command line (see https://github.com/qgis/QGIS/blob/master/INSTALL.md#4321-build-with-an-sdk) and copy paste the output to gist.github.com and share it here, this would nake things easier.

I have the output from Visual Studio build that I ran yesterday, would that suffice so I don't have to build everything again and wait another 4+ hours? I can post to gist and share that here.. Would that help? or does it need to be command line.

(see https://github.com/qgis/QGIS/blob/master/INSTALL.md#4321-build-with-an-sdk)

and yes, those are the instructions I am following

[danodom-tcb]

@m-kuhn , https://gist.github.com/danodom-tcb/850d921eafbf028b2aa7b740e7dce5e8

This was with WITH_QSCIAPI=FALSE.

I can switch this back and run it with that and paste the results later today after the build completes.

[danodom-tcb]

that one is truncated in gist.. the full output is here.

https://gist.githubusercontent.com/danodom-tcb/850d921eafbf028b2aa7b740e7dce5e8/raw/db5a5e0a616a5b3a6c7d5af4f811772d2cedce4c/gistfile1.txt

[m-kuhn]

Interesting, the last line says

========== Build: 543 succeeded, 0 failed, 0 up-to-date, 25 skipped ==========

the 0 failed looks like a full success you should have a C:\QGIS\QGIS\build\output\bin\Release\qgis.exe to run

[danodom-tcb]

Yeah, but when I run the executable, I get the same error I was getting in the build before we turned off that option.

[m-kuhn]

Oh, now it starts making sense ...

When we build a package (after the build) we also copy a few dependencies from the SDK to the final directory: https://github.com/qgis/QGIS/blob/master/cmake/VcpkgInstallDeps.cmake

could you copy the bin/Qt6 folder from the sdk to the build folder? (and you will find a few other files in the link above which will need to be copied)

[danodom-tcb]

Oh, now it starts making sense ...

When we build a package (after the build) we also copy a few dependencies from the SDK to the final directory: https://github.com/qgis/QGIS/blob/master/cmake/VcpkgInstallDeps.cmake

could you copy the bin/Qt6 folder from the sdk to the build folder? (and you will find a few other files in the link above which will need to be copied)

There isn't a bin/Qt6 folder in the sdk zip file, Just to be sure, I traversed the original zip that I downloaded. Qt6 is down under site-packages, but there's not a bin/Qt6 anywhere.

[roya0045]

Yeah, but when I run the executable, I get the same error I was getting in the build before we turned off that option.

you can use programs like dependency walker or ldd to view what might be missing/unlinked.

[danodom-tcb]

@m-kuhn is there supposed to be a Qt6 folder under /bin? if so, I wonder if that's the issue I may have been having with the QSCIAPI=true and failing in the same manner.

[danodom-tcb]

@m-kuhn so, I just found something and let me know maybe if this is the issue.. I linked to here, and there is a 2nd download

https://nightly.link/qgis/QGIS/workflows/windows-qt6/master

I opened that zip and there is a bin/Qt6 folder in it.. Is the link on the install.md pointing to the wrong SDK/Zip file?

[m-kuhn]

my bad, confirmed, the Qt6 folder is toplevel, not in bin in the SDK (as listed here https://github.com/qgis/QGIS/blob/master/cmake/VcpkgInstallDeps.cmake#L25)

[danodom-tcb]

@m-kuhn , so it goes further now..

it brings up a splash screen saying "QDev" in the center of it.

Looks like the messages at the bottom go through :

1. Setting up the GUI
2. Loading Python,

then it just exits, no errors or anything.

[danodom-tcb]

@m-kuhn I checked the Windows event viewer and this is showing up every time I run it.

Faulting application name: qgis.exe, version: 0.0.0.0, time stamp: 0x6719279c Faulting module name: ucrtbase.dll, version: 10.0.20348.2461, time stamp: 0xeb78ec60 Exception code: 0xc0000409 Fault offset: 0x000000000007caee Faulting process id: 0x2b78 Faulting application start time: 0x01db2628bc9595d3 Faulting application path: C:\QGIS\QGIS\build\output\bin\Release\qgis.exe Faulting module path: C:\Windows\System32\ucrtbase.dll Report Id: 27957198-7bc5-4b5e-9a4c-634e01cd084b Faulting package full name: Faulting package-relative application ID:

[m-kuhn]

That's better already, can you also copy the other files listed in https://github.com/qgis/QGIS/blob/master/cmake/VcpkgInstallDeps.cmake ?

[danodom-tcb]

@m-kuhn , do I need to just focus on the ones with the bin folder as the target?

I did miss this, but not sure how to read this, does this move everything except the .sip files to the bin folder? I think that is how it should be interpreted, but not sure..

install(DIRECTORY "${VCPKG_BASE_DIR}/tools/python3/" DESTINATION "bin" PATTERN "*.sip" EXCLUDE)

[danodom-tcb]

I assume that is supposed to move all subfolders as well?

[m-kuhn]

Yes, you have interpreted everything correct. This all should be automated in some way.

[danodom-tcb]

@m-kuhn closer I think..

What do you need from this?

[m-kuhn]

Probably something went wrong when copying the contents of pyhton3 Does bin/Lib/__future__.py exist (taking this as an exmple for a file that should exist)

[danodom-tcb]

Probably something went wrong when copying the contents of pyhton3 Does bin/Lib/__future__.py exist (taking this as an exmple for a file that should exist)

Just for additional context, the qgis.exe resides in bin/Release, so i've been putting what you requested in the bin/Release folder to align with where the exe is at.

that file exists there.

[danodom-tcb]

@m-kuhn ,I noticed in the full install from the Windows installer that an .env file is created that appears to have paths to dependencies.

Is this required to run and possibly be something missing?

[danodom-tcb]

@m-kuhn , so I think I just have maybe opened up a door here. I took the executable that I built, moved it over to an install folder on a Windows VDI with QGIS installed, It initially threw an error, but when I copied the existing environment file and renamed it to qgis.env from qgix-ltr-bin.eve. It started working on the VDI and launched

What I'll do next is move that env file to the bin/Release folder on the Windows Server and see if I can get QGIS to launch.

[danodom-tcb]

@m-kuhn is there one of the projects in the VS solution that's supposed to build out the entire set of build artifacts so that this will run? or are there other things that need to be done post-build that need to be added to the install.md documentation?

Since this is my first go in this process, I didn't/wouldn't have any insight to what would need to be done post-build to get this to run.

[danodom-tcb]

@m-kuhn how much of these should be located in the SDK? This is the one from the installer that I copied and renamed for the newly built .exe that worked.

PATH=C:\PROGRA~1\QGIS33~1.11\apps\qgis-ltr\bin;C:\PROGRA~1\QGIS33~1.11\apps\grass\grass84\lib;C:\PROGRA~1\QGIS33~1.11\apps\grass\grass84\bin;C:\PROGRA~1\QGIS33~1.11\apps\qt5\bin;C:\PROGRA~1\QGIS33~1.11\apps\Python312\Scripts;C:\PROGRA~1\QGIS33~1.11\bin;C:\Windows\system32;C:\Windows;C:\Windows\system32\WBem GDAL_DATA=C:\PROGRA~1\QGIS33~1.11\apps\gdal\share\gdal GDAL_DRIVER_PATH=C:\PROGRA~1\QGIS33~1.11\apps\gdal\lib\gdalplugins GDAL_FILENAME_IS_UTF8=YES PDAL_DRIVER_PATH=C:\PROGRA~1\QGIS33~1.11\apps\pdal\plugins GISBASE=C:\PROGRA~1\QGIS33~1.11\apps\grass\grass84 GRASS_PROJSHARE=C:\PROGRA~1\QGIS33~1.11\share\proj GRASS_PYTHON=C:\PROGRA~1\QGIS33~1.11\bin\python3.exe OSGEO4W_ROOT=C:\PROGRA~1\QGIS33~1.11 PROJ_DATA=C:\PROGRA~1\QGIS33~1.11\share\proj PYTHONHOME=C:\PROGRA~1\QGIS33~1.11\apps\Python312 PYTHONPATH=C:\PROGRA~1\QGIS33~1.11\apps\grass\grass84\etc\python; PYTHONUTF8=1 QGIS_PREFIX_PATH=C:/PROGRA~1/QGIS33~1.11/apps/qgis-ltr QT_PLUGIN_PATH=C:\PROGRA~1\QGIS33~1.11\apps\qgis-ltr\qtplugins;C:\PROGRA~1\QGIS33~1.11\apps\qt5\plugins VSI_CACHE=TRUE VSI_CACHE_SIZE=1000000 O4W_QT_PREFIX=C:/PROGRA~1/QGIS33~1.11/apps/Qt5 O4W_QT_BINARIES=C:/PROGRA~1/QGIS33~1.11/apps/Qt5/bin O4W_QT_PLUGINS=C:/PROGRA~1/QGIS33~1.11/apps/Qt5/plugins O4W_QT_LIBRARIES=C:/PROGRA~1/QGIS33~1.11/apps/Qt5/lib O4W_QT_TRANSLATIONS=C:/PROGRA~1/QGIS33~1.11/apps/Qt5/translations O4W_QT_HEADERS=C:/PROGRA~1/QGIS33~1.11/apps/Qt5/include QGIS_WIN_APP_NAME=QGIS 3.34\QGIS Desktop 3.34.11 SSL_CERT_DIR=C:\PROGRA~1\QGIS33~1.11\apps\openssl\certs SSL_CERT_FILE=C:\PROGRA~1\QGIS33~1.11\bin\curl-ca-bundle.crt

[m-kuhn]

One note, I guess https://github.com/qgis/QGIS/issues/59211 gives some hints for some of the original problems.

I am also running a build right now, to validate the instructions and improve.

[danodom-tcb]

One note, I guess #59211 gives some hints for some of the original problems.

I am also running a build right now, to validate the instructions and improve.

Awesome, happy to contribute here as well to improve this process. If you need me to validate/verify/etc. anything on my side, please let me know.

Just to note, there are a number of things I am not finding in the SDK from the .env file I posted above.

GDAL_DRIVER_PATH=C:\PROGRA1\QGIS331.11\apps\gdal\lib\gdalplugins PDAL_DRIVER_PATH=C:\PROGRA1\QGIS331.11\apps\pdal\plugins

I have searched for some of the plugins that were installed via the installer in the bin/ and the sdk/ and not finding them.

Should the .env file be generated as part of the build process? is this a separate project, or maybe one of the ones that are not a dependency?