There is a problem, app still need MSVCR100.dll and MSVCR100.dll.
Build QT source:
set QMAKESPEC=win32-msvc2010
configure -platform win32-msvc2010 -static
nmake
After install i am setuping my project ans set options to /MT /ZI. Still - my project wants MSVCR100.dll and MSVCR100.dll.
It is supposed to be that way.
From the QT documentation:
"Qt is built using the -MD(d) switch, which links against the dynamic C/C++ runtime libraries. This is necessary as we have experienced memory problems when using anything but the -MD(d) flag, and in general, it is recommended to use. You should not alter this flag yourself for your application, because it conflicts with how the Qt library is built if you change the flag to -MT. You should not change it for Qt either, since it is likely to cause problems"
More info can be found here:
http://qt-project.org/faq/answer/why_does_a_statically_built_qt_use_the_dynamic_visual_studio_runtime_librar
You are supposed to use the dll versions of these libraries and include the redistributable support install - it's the microsoft prefered way for several reasons (mostly to do with security updates)
My guess is that even with -static Qt uses some runtime component that uses the dll (possibly webkit or the multimedia classes that use MS features)
Related
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.
When I compile C++ code that uses openmp libs with visual studio, the program is very portable - because it runs in other machines with Windows without problems.
When I compile the C++ code with Eclipse CDT (oxygen and g++ cygwin) for Windows, in general, I need to install the correct runtime libs in the other machines to be able to run the program. I don't find it practical.
Based on this:
1) What is the right way to compile the code including all libs (g++ and openmp) to run in another Windows system?
2) How can do this in Eclipse CDT for Windows?
The problem is not in compiling, but in distributing. Windows and windows toolchains intend to use dynamic linking. Now, if created software are dependent on particular version of runtime, which includes side-by-side build, they can be run only if exactly that build is installed. Several builds of same library version may exist, they are fetched using side-by-side (SxS) mechanics.
On Linux platform this problem is solved through package manager and dependencies. On Windows you have to create an installer, which would contain or have ability to download proper version of libraries. Also installer may do proper changes to OS settings, and register them , for future rollback.
Note, that runtime libraries have debug variants which cannot be distributed and debug build of software must be run on developer system only.
"Portable" apps that appear here and there and can be run without installation, have special status not to be dependant on SxS run-time library. To my knowledge cygwin and mingw32 allowed to create such, the 64bit project of mingw had problems with that. But they are still dependant on particular versions of system .dll and may break or malfunction in case of mismatch.
Even in that case you still need some .dll, from mingw, cygwin, Qt, whatever you use and what is not a part of OS, to place them where program can reach them. Which can be folder comtaining the executable. Static linking became a gimmick of past for desktops, because of code bloat - dynamic library size easily can be dozens of megabytes.
And last: you don't compile anything with Visual Studio or with Eclipse CDT. Both designed to use various compilers, it's juse environments. You have to specify normal;y, what compiler your IDE uses, not what IDE you use to run ot.
I have written a shared library in C++ using qt creator and QMake
When I compile my project with MinGW compiler, I need the libraries libgcc_s_dw2-1.dll, libstdc++-6.dll and libwinpthread-1.dll to be copied next to my DLL in order to work. Which has about 1.5 megabytes size.
When I compile my project with MSVC 2015 compiler, I need to install the Visual C++ Redistributable 2015 x86 on the deployment system. Which has about 13 megabytes size.
My project has less than 100 kiloobytes size so these dependencies are so big.
How can I embed them into my library? or How can I have fewer dependencies to be installed or copied next to my project in Windows 7 or upper?
PS 1: I have read this, but the MinGW method was the same as before. And I encountered errors in Microsoft Tools method.
PS 2: Maybe .Net Framework 2.0 is a better option because it is preinstalled on Windows 7 and we can force .Net 4.5 to run it in Windows 8/8.1/10. Don't you agee?
Just link standard libraries statically. Your DLL size will increase obviously (I hope it isn't a problem) but not that much (<1 MB).
To do that:
If you use MSVC add /MT to command line (you can find it in project properties window too).
If you use g++ add '--static' .
I think you can't do that, your project must be set on static or dynamic link, not both of them together.
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.
I want to ask your opinion about one specific aspect of endless "Qt vs wxWidgets" question. Using wxWidgets in Windows, I may continue to work with my prefered build tools and compilers (in my case, Visual Studio). I only need to add wxWidgets include and lib directories to the compiler/linker path. When necessary, I just open some wxWidgets form designer (like DialogBlocks) and make form layout. Executables don't have any additional dependencies and don't cause any problems in redistribution.
On the other hand, Qt comes with its own IDE which tends to be the main development tool (which I don't want). It installs MinGW. It uses qmake, this is one more challenge in integrating Qt to existing build environment. I don't know how to use my existing libraries, developed with VC++, in Qt application. Can I continue to work with Visual Studio or I need to switch completely to Qt Creator? Or use both, building everything but UI in Visual Studio, and UI in Qt Creator? How Qt-based application can be redistributed: should I require MinGW installation on target computer?
How all these problems are solved - I need some directions and opinions from C++ developers working with Qt in Windows.
Edit: It looks like most promising directions are Visual Studio plugin and CMake. I found that Qt plugin supports VS2010, but it requires rebuilding Qt from the source. For VS2008 this plugin works with binary Qt installation - good enough.
You don't have to use the whole Qt SDK, you can only install the libraries for VS (or build from source, if you prefer. The pre-built libraries are for VS2008 but there is a makespec for VS2010 so you can build one yourself, if necessary) and use the Visual Studio integration.
You can use Visual Studio. There is a Visual Studio integration plugin that makes it a lot lot easier to develop with Qt in Visual Studio.
As for the wxWidgets vs Qt debate... I use both (on different projects). I have to say that I would rather use Qt - it has fewer bugs IMO and in general there is an easier workaround if you have problems with the framework (Qt4 is much better in this regard than Qt3 was because the 'pimpl' data is accessible). However, distribution is slightly more complicated with Qt as you must make sure that you have set included any plugins correctly in your distro (be sure to check that it works on a clean machine that does not have Qt installed).
You can download the Qt "source-only", take a look here for the latest version. You can build this library youself using the provided configure tool and MS' nmake...
For example, my typical build looks like this:
configure -shared -release -opensource -no-webkit -nomake demos -nomake examples
nmake
This will build release-mode Qt dlls, assumes you want to use the LGPL-license (with the -opensource flag), no webkit and upon calling nmake it will not build the demos and examples... Of course, you will have to take a look at all the possible options provided by configure
You don't have to use Qt Creator, many people use other IDEs or simple text editors.
qmake is not difficult to use, from a template config you can easily modify a project file by hand. In fact qmake will generate a basic project file for you to get started with.
Use existing libraries as you would in any other project.
You don't need to require a mingw install, you can include essential DLLs in your application directory; but this is the same problem as any other "DLL hell" problem.
If you use cmake as a build system, you can use that to generate project files for visual studio (and eclipse, and ordinary Makefiles, and ..., on any OS). Just install the cmake GUI and select visual studio [myversion] in the appropriate dropdown menu. The only thing to remember then is that you need to make changes to the structure of your project (e.g. adding files) to the cmake CMakeLists.txt files.
Setting up cmake + Qt is pretty easy, and you only have to figure it out once. Googling around a bit should get this setup running in no time.