I'm doing a very small windows application consisting of just a single executable. As the program will reside on a SD card I want the application to be as self contained as possible, and I'd rather not have an installer. I'd want the user to be able to simply copy the executable to the SD card and be able to run it straight away without fiddling with anything extra. The problem then becomes the fact that my program is compiled with VS 2008 which requires versions of the CRT which I can't guarantee is installed. I'm linking statically to the CRT, which I incorrectly thought would circumvent this problem. I've been thinking of tracking down some older VS version, but I have a feeling this is the incorrect path. I want the program to run on a fresh install of windows xp and above.
Grateful for any help.
Linking statically to the CRT using /MT or /MTd (for debug) should do exactly what you need.
The fact that it isn't suggest that there is still something that depends on the dynamic library. That would be the case if you has some additional DLLs which are not compiled with the static CRT.
you can use the dependency walker (depends.exe) to figure out exactly which dlls use which and who still depends on the dynamic CRT or in any other DLL.
Another approach is to run your exe from the debugger and see which DLLs are being loaded in the output window. Which depends.exe gives you only the dlls loaded on the startup, this can give you some additional dependencies that are loaded only on runtime.
If you want the link against the DLL version of the CRT libraries and you want to avoid installing anything then you need to copy every member of the CRT assembly into the same folder as your executable. It may not be the way that Microsoft pushes you towards but it is valid and it does work.
In your Visual Studio 2008 install directory your should find a folder: VC\redist\x86\Microsoft.VC90.CRT. If you copy the complete contents of that folder (including the manifest file) to the same directory as your executable then you should be able to run the executable from that location.
Related
I'm reading about /MT and /MD, but I'm a little confused about it
HEAR is something I don't completely understand :
/MT Causes your application to use the multithread, static version of the run-time library. Defines _MT and causes the compiler to place the library name LIBCMT.lib into the .obj file so that the linker will use LIBCMT.lib to resolve external symbols.
what does it mean?
If you link with /MD or /MDd your program is going to need the CRT dlls in order to run. typically they are called something like msvcp100.dll for the C++ runtime and msvcr100.dll for the C runtime. If you are deploying your application using an installer, you can add a package with these to your installer so the dlls are going to be there when someone runs the application. If on the other hand you are going to deploy your application just as a single stand alone exe, your users are going to need a copy of these dlls. The latest versions of these dlls usually come with windows itself (not the debug ones) but if your user is running an older version of windows it may not have the needed dlls.
Linking your application to the static version of the CRT saves this whole headache for the price that the exe is slightly bigger (since it contains the CRT in it)
If you do use /MT (Static CRT) you have to make sure that everything else that you statically link with uses /MT as well. otherwise you'll end up with an executable where part of the code uses the static CRT and part is still depends on the CRT DLL. Other than defeating the basic purpose not needing the CRT DLL, this can also cause other problems.
To make sure what DLLs your exe depends on you can use the dependency walker.
Quick question here, okay say that I have downloaded additional libraries and added them to my version of visual studios and have their #include and commands in my project source code.
If I was to take the .cpp file and bring it to my school computer which also has visual studios and doesn't have these additional libraries, it would have a bunch of missing errors and can't compile.
but..
What if I publish my project and I have it in a .exe file and I was to try and run it on another computer that doesn't have these libraries? Would the executable file run okay?
When you
#include <stuff>
stuff is used during compilation time. However, the libraries it may refer to (e.g. the include gives the definition of many functions from an external library), can be
static or
dynamic
static libraries are linked statically when the program is built, and are part of the executable. dynamic libraries like DLL are linked during the execution of the program .exe. Thus they (DLL) may not be present on another computer when you run the same exe on it.
It depends on the libraries you are using, but sometimes a package is available for download and installation on the other computer, so that they become available. Sometimes you have to copy a bunch of DLLs along with your exe to the other computer. For instance, some advice from Microsoft in this regard.
I have a Visual Studio 12 project; source code written in C++; it's an OpenCV project. I want to give my compiled program to someone else, but, on other PC, I getting an error message about missing some dlls. My program using many OpenCV (maybe, not only) dll's. How can I resolve that problem? Maybe in VS 12 available an option to include all dll's in .exe?
It's a pretty similar question without proper answer:
include dlls in visual studio c++ 2008
DLLs themself can not be "statically linked" into an executable; that completely defies their purpose (well, actually you can use some really weird voodoo tricks to actually do it, but this is neither recommendable nor should you try it if you have to ask this question).
The simple solution would be to identify all the DLLs your program requires (just starting the program in the Debugger will generate a log file listing them all) and copy those DLLs into the same directory as the EXE resides in; as it happens the directory with the EXE file in is also the first directory where the system looks for DLLs before advancing to the standard system directories in default configuration. Package it up and distribute it that way.
the more complicated solution would be, to build static opencv libraries from src, then link your program against those, resulting in 1 large binary exe-chunk, that does not use any dlls (apart from ffmpeg, not sure about that one).
to build static libs, you'd need to run cmake with : BUILD_SHARED_LIBS=OFF
but take a deep breath, before doing that. linking your program will be sigificantly more difficult, because now you have to link all the zlib,libpng, whatever dependecies manually ( which before got conveniently linked into your dlls )
again, the most simple solution is to deploy all the opencv dlls with your program.
You can use the Windows Dependency Walker to determine which DLLs your program needs to run.
Actually, this only tells you which DLLs your program needs to launch successfully. If you load DLLs dynamically (via LoadLibrary) then you are on your own.
If you opt for the accepted solution (package the DLLs with the EXE file), and you don't want to go into the trouble of finding which DLLs to use, then you can copy all the OpenCV DLLs. They're not so big (65 MB on OpenCV 2.43). They are located at ...\opencvXXX\build\x64\vc10\bin\
where XXX is the OpenCV version. You can use x64 or x86 depending on your platform (32 or 64-bit). And the version of vc can be different on your system (vc9, vc10, etc...)
I am developing an application in VS2005 which uses Boost 1.54. After messing up with compilations, I decided to download the "alredy baked" VS8.0 Win32 binaries, and there they go.
Now the thing is, the application is being generated with the /MD option, which means, correct me if wrong, that it is being dynamically linked (external dependencies shall be provided in means of DLL files).
I have used Boost::Thread in my application, and it runs fine in my computer. As it is generated with /MD, it is supposed to require DLLs in other computers, isn't it?
However, when asking a peer (who does not work with Boost) to run my app, it simply runs fine. Wasn't it supposed to shout with a DLL missing error?
Thanks.
/MD is a flag dedicated to the C run time, it is not related to Boost.
By default, i think Visual Studio links statically Boost. If you want to link dynamically, you need to add a flag BOOST_ALL_DYN_LINK
Also, i would recommend the excellent Walker Dependency whenever you want to check dynamic dependencies
I have a dll that I distribute that will not run on some windows OS. Using dependancy walker I discover msvcp90d.dll missing on these systems. I DO NOT want any run time dependancies that require the C++ redistributable, and since the application that calls the DLL is not written in C++, it does not have any dependancy on the C++ redistributable.
I am guessing the I left the DEBUG option in the linker preferences on when I compiled the dll which is why it needs msvcp90d.dll?
ADDED:
Appologies, I pasted the wrong dll name in my original question.... too many hours in front of the monitor...
THe dll is a third party dll that I did not write compiled by me in VS2008.
MSVCP90 is nothing to do with debug (that'd be msvcp90d). You can remove your dependency by switching the compiler to /MT (instead of /MD). You also need to ensure that every static library you link to was also compiled /MT.
I recommend against building apps /MT because it has a significant negative effect on system performance and makes servicing take longer in the event of a security issue with the CRT.
Finally, note that /MT means that your CRT is private. So you must ensure that CRT/STL types don't pass across your DLL boundary.
Martyn
Your options as I see them:
Compile the DLL with the /MT option to use static linking to the C runtime.
Continue with dynamic linking to the runtime, but distribute the C runtime with your app.
It needs MSVCP90.dll because the dll was compiled with Visual Studio 2008 most likely. That is the release runtime. The short answer is if you don't want C++ runtime dependencies don't use C++ libraries or applications.
However you can do any of the following to solve your problem:
Install the redistributable to the target system to satisfy the dependency
Remove the dependency on that dll from your application
Recompile the dll against the version of VC you prefer that is already present on the target system