I tried running a QT C++ GUI sample in WinPE. It should just open an empty window.
It complains about missing d3d11.dll and dxgi.dll.
QT tries to use OpenGL, if there is no suitable driver, it uses DirectX with ANGLE. I tried removing the DirectX dependency by calling Qapplication::setAttribute(Qt::AA_UseSoftwareOpenGL) before the Qapplication instantiaton. No change, still requires those two dlls.
I tried to copy those two files from my regular Windows, and now the error is: “The procedure entry point CheckIsMSIXPackage could not be located in the dynamic link library dxgi.dll”
I don't need any HW acceleration, how could I make it run?
QT version: 5.14.2 (dynamic linking)
WinPE version: Windows 10 2004
Compiler: Visual Studio 2019 and Mingw 8.1 (I have tried both, same results)
Too late ? Not the solution but only an idea.
Actually I use Winpe WinPe 2009. When i install VirtualBox 6.1.16 in this winpe, i add opengl32.dll and other files. VirtualBox uses QT5 files. And i get the same error. With Depends.exe, i see that opengl32.dll needs this ChechIsMSIXPackage and loock for it in kernelBase.dll. But because kernelBase.dll which comes with winpe2009 doesn't contain this API, i take this kernelBase.dll from a normal W10 (in the ISO/Install.wim). And, in my case, virtualBox works well, QT5 also, opengl32 also.
Qt 5.12 does not depend on dxgi.dll but Qt 5.15 definitely seems to.
One option is to roll back your project to Qt 5.12, I can personally confirm that Qt 5.12 projects work great under Windows PE.
(This is assuming you are using the prebuilt Qt binaries from Maintenance Tool - otherwise there may be a config option to recompile Qt to avoid this).
It's late but since I just ran into this problem myself...
Apparently this dependency is introduced by the Rendering Hardware Interface, and what worked for me for WinPE 1809 was to build Qt 5.15 (.7 and .8) from source - in Msys2, by the way - after removing/commenting out the line include(rhi/rhi.pri) in qtbase/src/gui/gui.pro, and the configure command line includes -no-directwrite -no-opengl -no-icu.
Related
I'm learning c++ and want to start learning qt.
I have installed the qt creator, but when I want to create a new project, it shows me an error saying " no valid kits found".
I searched the internet and finally figured out that I should install some components first.
Now I'm in "D:\qt\MaintenanceTool -> Add or remove components" and here is a huge list of components that I can install, at first I wanted to install all of them but It's like 50GB and I'm pretty sure that I don't need to install them all at this point, I'm just trying to start to learn qt.
Which Component do I need to install? I want to create desktop applications that can be run on win 10/8 or maybe 7 on 64 bit (Windows 10 is the most important one)
Is there anything else that I should do beside installing components to get rid of "no valid kits found"?
I compile my c++ codes with MinGW and I write codes using CLion ide.
Thanks in advance.
You just need the Qt pre-compiled binaries.
So one of the MSVC components there (if you use visual studio) or one of the MinGW (select this one if you are not sure).
Note: If you select MinGW, you need to make sure that the version (32-bit or 64-bit) matches the same MinGW that you have. If you are using the one that comes with Qt, you can check it in Developer and Designer Tools:
That's all you need to get started.
Selecting MinGW 7.3.0 will be enought. Just choose proper 32/64 bit version - the same as in case of your mingw installation.
You should choose the following:
If you don't have any compiler then select it in Developer and Designer Tools. Also you can select Debugging Tools for Windows.
Then select appropriate pre-compiled binaries of Qt for selected compiler.
That's enough.
After cleaning and reinstalling windows 7, I've installed qt 5.11. However, my old plugin (dll) which I developed using qt 3 is no longer recognized by the application. But the application recognizes the dll in debugger mode.
I have tried copying dependent libraries which the debugger loads to the dll location but this has not worked. I have also removed references to qtcore etc but even this has not worked. I do not know what I am missing.The plugin ran fine in the old version of qt but not in the newer version of qt.
Thanks for any help that you can give.
Qt does not provides binary backward compatibility between major versions.
You must update (== compile and build your plugin dll with Qt5) to have it working.
see this page
https://wiki.qt.io/Qt-Version-Compatibility#Binary_Compatibility_Guidelines
I'm stuck in a deployment issue with my Qt 5.4.0 application.
After two days of research, my app really doesn't want to execute on Windows XP !
I have created my deployment folder with windeployqt provided by my Qt installation. When I double-click on *.exe, I have always :
The procedure entry point vsprintf_s could not be located in the dynamic link library msvcrt.dll.
Dependency walker hasn't really helped me and I don't know what I can try now.
Note :
SDK : Qt 5.4.0 (MSVC 2010, 32 Bits)
IDE : QT Creator 3.3.0
Compiler : MinGW 4.9.1 32 Bits
Need to run on : Windows XP Pro SP2 32 Bits
App works like a charm on Windows 7 with same configuration (IDE, compiler, etc.)
While Guilhem G. is correct in the broader sense, it doesn't mean you actually called that function yourself (speaking now to a theoretically other person running into this issue like me, heh). I believe it's a bug with MinGW's XP support; I've seen bug reports of similar issues, including nearly the exact same issue in a much earlier version of Qt that was then fixed. I haven't seen this particular incarnation, which I actually ran into myself. I suppose I should probably submit a bug report!
Anyways, I've fixed it without changing any of the code I've written myself. What I had to do to fix it was twofold:
Switch over to using the msvc2010 compiler, since that set of C++ libraries rather unsurprisingly runs fine on Windows XP (AFAIK they still haven't dropped XP support with the latest version).
Switch over to Qt 5.5 (I'll explain why at the end).
For the compiler, you'll need then either Microsoft Visual Studio 2010 (hence the name), or the older Windows SDK that ships with it; the "Microsoft Windows Software Development Kit for Windows Server 2008 and .NET Framework 3.5" release should do the trick for you if you don't have a Visual Studio 2010 license.
Once one of those is installed, I'd encourage you to install Qt 5.5 as compiled by MSVC2010. You can either start a fresh installer or use the Qt Maintenance Tool which should already be installed.
Once that kit is installed, within your project (selecting "Projects" from the left-side menu) you should be able to go "Add Kit" and select Qt 5.5 msvc2010 32-bit, and if you now recompile and redeploy your application, it should run fine on XP.
Now, why did I insist on you upgrading to Qt 5.5? Well, there's some underlying issues with choosing a working OpenGL renderer on each version of Windows, and Qt 5.5 simplifies that a lot by having it fall back on OpenGL or ANGLE depending on what capabilities are actually detected, plus IIRC some other related fixes. So certainly if you're deploying a QML / Qt Quick 2.0 app across multiple Windows versions like I'm doing, it's worth upgrading to Qt 5.5.
The error was I called "sprintf_s" somewhere in my code (ok for recent windows on my dev machine but not for XP).
If you have the same problem when you search in your code don't use exactly the name of the function in the error message but an expression like *_s.
You probably call a secure API function somewhere !
I have installed (and reinstalled) the QtSDK Community version on Windows 7 64-bit. When I launch Qt Creator there is no option for C++ Project. Others have solved this problem by making sure qmake.exe is properly detected under Tools-->Options-->Build & Run-->Qt Versions but it appears to be in my installation:
First go to File->New and check the drop-down box in the top right: Is it set to show the relevant templates ("All templates" is the save bet).
If it does: Please check the Kits tab in Tools>Options>Build & Run: Is there a kit using the desktop device type with a compiler and Qt version? Do compiler and Qt version match (same type and version)?
With the Qt in the screenshot you need to have MSVC 2013 set up and detected. MSVC 2010 or any other version does not work, nor does mingw since the binaries that result from building with one compiler and linking to a Qt built with a different compiler does tend to crash more or less randomly.
Once you have a Kit with a Qt version the additional wizards should become available.
I have a Qt application using Qt 4.8.5. This application is dependent on a DLL that was built using Qt 4.6.0. Let's call it "MyDLL.dll".
I cannot rebuild MyDLL.dll to update it to a more current version of Qt. Since both my application and MyDLL require the QtCore and other DLLs, and the versions are different, how do I organize my files such that they don't conflict?
MyDLL is required at startup, so I can't use any delay load methodologies.
edit: To be clear, this question came up because the MyDll.dll was built using a custom Qt 4.6.0 from modified source, and my application is using a custom build of 4.8.5. The modifications weren't necessarily the same in both versions, so I didn't want to assume that I could still use the 4.8.5 DLLs. Turned out that it worked out in this case, but the question stands.
You shouldn't be having any issues. Qt maintains binary compatibility over minor and patch releases (see http://qt-project.org/wiki/Qt-Version-Compatibility) and an application/DLL built with 4.6.x will run fine when bound to 4.8.x runtime.
Your MyDLL.dll built with 4.6.0 will run with 4.8.5 runtime DLLs.
Your application built with 4.8.5 will run with 4.8.5 runtime DLLs.
Your application will run fine with MyDLL.dll as long as you are using the same interface you've always been using.
If you are seeing issues it is because of something else, and you will need to clarify exactly what problem you are having.
If you are not seeing issues and are just asking preemptively, then 1) just proceed as normal with no special considerations, and 2) you should have tried it first!
Welcome to DLL Hell! :(
This is a huge problem under Microsoft windows, since the standard isn't to build version information into the DLL file name (like with Linux .so files).
You won't be able to accomplish what you are after if you link directly against "MyDLL.dll" since it will be looking for QT DLLs (like QtCore, QtGui, etc). The stock Qt DLLs contain no version decoration in the filename, so there will be a conflict as to which one to load. Also, you will likely not be able to link correctly in the first place (due to the conflicts. Qt doesn't play well with older versions).
The only possibility might be to create a separate executable that links against Qt 4.6.0 and MyDLL, and use some out-of-process communication between your main app and the server. COM might work in this case, but it largely depends on what your dll actually does.
The only other course of action would be to downgrade your main application and fix it at Qt 4.6.0.
Jason C's answer got it right. Also note the following:
MyDll.dll must be compiled with the same compiler version as the rest of your application.
The version of Qt used to build MyDll.dll should have had the same major configuration flags as the version of Qt that you're currently using. Things such as Qt namespaces, QThread support, etc. must all be the same.