I'm trying to write a rather simple ActiveX using c++ code. Problem is that Release binary has dependency at MFC90.DLL and MSVCR90.DLL which does not apear at the Debug. How to attack this??
You can try statically linking MFC and the C++ runtime libraries, which might be desirable because then you won't have to hope users have the VC++ runtime redistributables installed.
Or you can install the VC++ redistributables that will install those shared libraries.
I believe you can also include those missing DLLs in your CAB file (assuming you're installing this as a download via a web browser), but you might as well try to statically link if you're going to do that.
Debug builds can still use release DLLs/libs, it just means you can't step into the code for those parts when debugging.
It's perfectly normal, unless I misunderstood the question?
Related
I'm totally new in using Qt and I don't know a lot of stuff.
As a test I created a simple application using Visual Studio 2012 and Qt-VS-Add-in based on the newest Qt5.1
After I compiled the application it didn't work for me (gave errors), I searched all over the internet and found a lot of people saying that I have to copy those dlls mentioned below from the directory:
C:\Qt\Qt5.1.0\5.1.0\msvc2012\bin\
DLL's I had to copy to make my application work:
icudt51.dll
icuin51.dll
icuuc51.dll
libEGL.dll
libGLESv2.dll
Qt5Core.dll
Qt5Gui.dll
Qt5Widgets.dll
My problem is the size of these dlls, they're about "37 MB" and my application itself is only "30 KB"! So, those Qt libraries will add at least 37 MB to my application [ Which I don't see it happens with other Qt-based applications I download ]. Is there any solution can make me end up with a single small .exe file?!
And I heard some people saying that I have to also include a dll for Microsoft C++ Compiler, can you explain this for me?
Note: I've come across a lot of questions here on StackOverFlow but I couldn't find anything can help me, so please do not flag this as a duplication because if I found a clear answer I wouldn't post this question!
Any help would be appreciated.
UPDATE: Use windeployqt.exe! It works really well.
http://doc.qt.io/qt-5/windows-deployment.html#the-windows-deployment-tool
The simplest way to use windeployqt is to add the bin directory of
your Qt installation (e.g. ) to the PATH variable and then
run:
windeployqt <path-to-app-binary>
UPDATE: Upon Further testing, windeployqt did not copy over all the MingW dlls for me. (Tested with Qt 5.4 on Windows 10 with MingW 4.9.1). So you need to manually get the last 3 dlls before deploying:
libgcc_s_dw2-1.dll
libstdc++-6.dll
libwinpthread-1.dll
From
C:\Qt\5.4\mingw491_32\bin
I think you may have a few extras in your list... I would double check the docs in the links below...
Here is the definitive documentation on it:
http://doc.qt.io/qt-5/windows-deployment.html
http://doc.qt.io/qt-5/windows-deployment.html#application-dependencies
Size of Qt DLLs
The amazing Qt Libraries can do a lot, but they are kind of big. Some of the older versions of Qt might be a little smaller.
For Qt 4.8 msvc QtCore4.dll is 2.5 MB, and QtGui4.dll is 8.4 MB.
How Windows Resolves Shared Libraries/Dynamic Link Libraries (DLL)
Here is how Windows tracks down a library at runtime:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms682586(v=vs.85).aspx
Single Small EXE
If you statically link, then your EXE should grab the libraries it needs and gets built into a stand alone exe. It still may be dependent on msvc redistributables. See the next section for more info on it. But it now compiles down the .libs that you reference into your EXE and your exe no longer is pointing at other dynamically linked libraries. It does take more time to get your statically linked exe environment setup.
Your exe will certainly get bigger as it now includes the binary information for the libraries that you referenced before.
https://www.google.com/search?q=qt+static+linking
EDIT:
Statically building the exe, means that you aren't using the LGPL version.
means that you have to have your object files easy to access to end users if you are using LGPL.
I think #peppe described it well (see comment below):
Technically, you are allowed to statically link when using Qt under LGPL, even if your application is not using LGPL. The only tricky requirement is keeping the ability for a third party to relink your application against a different Qt version. But you can comply with that easily, f.i. by providing a huge object file (.o) of your application, that only needs to be linked against any Qt version.
http://blog.qt.io/blog/2009/11/30/qt-making-the-right-licensing-decision/
Look at the chart near the bottom. If you are doing the commercial version, then you can statically link, without worrying about the object files.
MSVC Redistributables
Redistributable dependencies have to do with the run-time library linker options.
http://msdn.microsoft.com/en-us/library/aa278396(v=vs.60).aspx
/MD, /ML, /MT, /LD (Use Run-Time Library)
To find these options in the development environment, click Settings on the Project menu. Then click the C/C++ tab, and click Code Generation in the Category box. See the Use Run-Time Library drop-down box.
These two links below talk about some older versions of visual studio, but the reasoning should still stand.
http://www.davidlenihan.com/2008/01/choosing_the_correct_cc_runtim.html
How do I make a fully statically linked .exe with Visual Studio Express 2005?
Hope that helps.
Just open your terminal execute your_qt_installpath/version/compiler/bin/windeployqt.exe YourApplication.exe. It will automatically copy all the required libs and stuff into the folder, where your exe is located and you can just distribute it.
For Windows you need to include qminimal.dll and qwindows.dll, you will have to put them in folder called platforms.
Even if you program is small you still call huge libraries to do the graphical interface. If the size is really important you should do a console project.
PS : You can check all the libraries you really need by opening your exe with the dependency walker.
I found another workaround without recompiling Qt again!
[ This solution may affect application execution time ]
First we need to use UPX to compress each one of Qt Libraries required by our application, they're often the dll's mentioned in the question. However, avoid compressing them too much because you'll notice that your application takes longer time to run.
[ Optional ]: If your application binary is large, you may find it useful to compress it using UPX.
After compressing all binaries, we want to get a single .exe file, so we can use
Enigma Virtual Box [ http://enigmaprotector.com/en/downloads.html ] to merge all .dll files with the main executable and we'll end up with a single tiny .exe file!
I'll just do it like this for now since I'm not able to recompile Qt with my own configurations on my current machine.
it looks to me that Qt5.2 requires fewer dll.
Qt5Core.dll
Qt5Gui.dll
Qt5Widgets.dll
in windows you also need "qwindows.dll" in folder "platforms".
give it a try.
A possibility for reducing the size of the DLLs is by compressing them with UPX as mentioned by Alaa Alrufaie. Another method is to wrap it into an installer (e.g. Inno Setup). The latter one is particularly useful if you want to distribute it to end users). I had a simple application requiring Qt5Core.dll, Qt5Gui.dll, Qt5Widgets.dll and qwindows.dll (in the folder "platforms") taking about 17 MB. After creating a setup file, it shrank to 5 MB.
I have made an allegro simple game . But when I open the *.exe file on another computer it says that there are many missing .dll files . How can I make my game to run on other computers without Visual Studio and Allegro 5 library installed ?
Longer version of my comment:
When you created your application, it links to certain DLL's that exist on your computer. When you distribute your game, you will either need to ZIP the DLL's along with your .exe or package them using package creators and ship it.
The best way to find which DLL's your exe depends on will be to use a tool like Dependency Walker. You don't need to copy absolutely all DLL's that your EXE depends on. Only the ones that you see are in non-standard paths like ones that are not in C:\Windows\System32. That being said, you might need to copy some from C:\Windows\System32. You will need to find that out on your own.
To package them all as a setup, you can use package creators like InnoSetup or NSIS. Otherwise, create a script that ZIPs it all up for you. AFAIK, there is no easy way to get all DLL's required that are missing from the other persons' system. You'll need to find them out by trial and error. It is a pain, unfortunately.
If you downloaded the pre-built binaries, link against the static, monolithic, mt build of Allegro. You'll need to adjust your compiler settings to match (/MT) and add ALLEGRO_STATICLINK to your list of preprocessor definitions.
If you do that, then you only need to distribute your executable file and your resources (images, sounds, etc).
Note that you should have at least two configurations: Debug & Release. When working on your application, you should use the Debug configuration (linking against the regular debug Allegro library). When distributing your application, you should use the Release configuration.
I am using VS2010 and am working with this project.
http://www.codeproject.com/KB/audio-video/Asio_Net.aspx
Initially, I downloaded the demo binary and it would crash on my machine. After reading through some of the comments, it said to download the source, build it, (after getting the ASIO SDK), and it should work on your machine. This is correct, after building it in VS it works, on that machine.
When I moving the rebuilt .exe and .dll to a different machine, it crashes with the same error as the originally downloaded demo binary. So I am unsure what would cause this. How can I make this C++ binary work on any machine??
I am a C# developer and most of the code is c++, so am kind of at a loss.
BTW, here is the error message:
"Unhandled Exception: System.IO.FileNotFoundException: Could not load file or ass
embly 'Bluewave.Interop.Asio.dll' or one of its dependencies. The specified module could not be found.at BlueWave.Interop.Asio.Test.TestConsole.Main(String[] args)"
EDIT: Answer found here:
http://msdn.microsoft.com/en-us/library/8kche8ah(v=VS.100).aspx
Use dependency walker to find which .dll is missing.
Assuming you mean that you've included this dll - Bluewave.Interop.Asio.dll then there only a couple of explanations I can think of:
One of it's dependencies is missing from the machine. You can use something like Dependency Walker to find out what's missing.
The dll is not in a location the exe can see (unlikely but you never know).
The missing dll may well be part of the VC++ runtime and not necessarily part of Asio.
What else is in the output folder on the machine where you built it?
I've downloaded that demo project from Code Project and I think the most likely cause of the problem is that the Visual Studio C++ 2008 runtime dependency is missing. Solve this by installing the runtime redistributable package on the machine.
Note: I checked the dependencies of this DLL using Dependency Walker. You can even run this in profiling mode so that it will tell you at runtime exactly which dependency is proving troublesome.
When I run the program from IDE (VS2008) it works perfectly. When I want to launch it from Windows Commander it doesn't work because it needs DLL that wasn't found.
Used both debug and release builds.
Make sure the Qt DLL's are in your PATH. Two simple solutions are:
Copy Qt's DLL's to your EXE's directory.
Copy Qt's DLL's to %WINDOWS%\System32 (e.g. C:\WINDOWS\System32) (possibly unsafe, especially if you install another versions of Qt system-wide. Also, requires administrative privilages).
You should make sure that the DLLs needed by the executable (probably QT Dlls) are in the PATH or in the same directory as the executable. You can find which dlls are needed by using depends.exe
another solution would be to place path to qt bin subdir in VS tools->options->projects and solutions->VC++ directories.
You could link it statically with all the libraries it needs. Saves messing around with DLLs and stuff. On the down side, you can't update DLLs on your installed PCs to get updated/improved/fixed functionality, and will need to rebuild and redeploy.
So whether or not this is viable depends on what your installation targets are - a few PCs controlled by you, or every man+dog who decides to download your program?
Statically compiling in a library bug (security hole for example) and shipping that to your clients would be very poor form. Doing the same on a secure corporate intranet may make it worth doing just so that you know that each install is running exactly the same.
I'm using boost for several C++ projects. I recently made a upgrade (1.33.1 to 1.36, soon to 1.37), since then I cannot run any debug-builds anymore.
To be sure that no other project issues remain, I've created a minimum test-project, which only includes boost.thread, and uses it to start one method. The release build can be started, the debug build cannot, although the Dependency Walker shows that all required libraries are found (this also means that the required MS Debug CRT is found in the SxS directory).
On startup I only get:
Die Anwendung konnte nicht richtig initialisiert werden (0xc0150002).
Klicken Sie auf "OK", um die Anwendung zu beenden.
Which means nothing more than "failed to initialize app". An internet research primarily lead to an MS Office installation problem, which recommends to perform a repair of WinXP.
So, beside the repair setup (which I think will not help as I'm talking about debug-dll issues), any ideas?
Ah, before I forget: Absolutely the same source-code leads to no errors on the build-machine (i.e., DLLs can be registered, means executed). So it's obviously an installation problem, but as the DLLs are there, and dependency-walker finds it, what else have I forgotten?
(edit) Well, I have not yet resolved my problem, but thanks to deemok I'm a step further. For the sake of reducing misunderstandings I give some clarifications below:
The program fails to run on the developer-machine
I am working with an installed VS2005 (it's a VC++8 project)
I used the boost-setup from BoostPro, compiled all possible build-versions, and I double-checked that they are there (otherwise I'd already get linker-errors during build).
and I double-checked any corner of include/lib/bin configuration I can think of -- as boost uses auto-linking on windows, with a special naming convention, the build or start-up would have failed, with a much more comprehensible error-message.
I cannot use static linking, as boost.thread requires dynamic linking for DLL projects (I maybe could mess around here, but as this problem seems to happen only on my machine, I do not want to mess with this, as I'm sure the boost-guys had a reason to place that check in there in the first place)
As I wrote, I checked with Dependency Walker, and it says everything is just fine.
Currently it seems to be an error in the boost-dll (maybe incorrect Manifest), will check that.
It's a Side-by-Side (SxS) issue – simply copying the DLLs is not enough anymore.
Regarding your specific problem concerning the Debug build, see: Running vc2008 debug builds on non-dev machines
Short answer:
You can't, because there's no installer redist for the debug runtime (and in fact the software license forbids distributing it, so you'd be breaking the EULA even if you did get something put together).
So, you'll need to install Visual Studio there.
However, if you still want to try without taking that path, you could read puetzk's answer in its entirety.
Or, you could try to link everything statically.
So you are using the pre-built libraries from BoostPro? If so, your environment might somehow be slightly different to the one they were built in (TR1 feature pack or not, etc). Perhaps best to try building Boost yourself in your specific environment.
This might turn out to have nothing to do with SxS. I suggest checking the Event Log for SxS error messages and using dependency walker to check for most probable DLL dependency issue, or one of the DLLs is returning FALSE from its DllMain (for whatever reason).
Also, enabling loader snaps:
gflags -i yourapp.exe +sls
might shed extra light when run under debugger (or dependency walker for that matter).
Note: gflags is part of Windows debugging tools.
Get yourself the dependency walker. Open your application exe in it. It will show you all the dlls that your application needs but can't load/access.
If that's not enough, you can also profile your app with the dependency walker, which will give you a lot of output to find out where the problem is.
[edit]
since you only have problems with the debug build:
make sure that when you upgraded boost, you also rebuilt not just the release binaries but also the debug binaries of boost. And of course, make sure that the debug build was built with the same version of VisualStudio than you're using now.
And make sure that the include paths (tools->options->projects and solutions->VC++ directories) are correct: the paths to the latest boost version must be there, not maybe to an older version.