I am compiling project in Visual Studio 10, compiled executable runs fine on win 7 but it doesnt works on win xp because of missing msvcrt100.dll.
I tried to use "/NOTDEFAULTLIB" but it also removes some other external libs that i use.
Is there way to not link against latest Microsoft runtime library ?
Thanks in advance.
To not link against the DLL you must link against the runtime statically.
To do this, go to C/C++ Properties -> Code Generation and under Runtime Library select Multi-threaded (/MT) or Multi-threaded Debug (/MTd) from the drop-down. Note, once you're using a static runtime library all of your other library code you link against must also be built with the same setting. And you will also likely have to add additional libraries to the Linker -> Input under Additional Dependencies.
It only works on Windows 7 machine by accident, somebody installed that DLL earlier.
Short from creating an installer (easy to do with a Setup project), a simple fix is copying msvcr100.dll along with your own binaries. If you only have an EXE then the simple solution is to link the static version of the CRT. Switch to the Release build, right-click the project, Properties, C/C++, Code Generation, Runtime Library setting. Change it to /MT from the default /MD.
Related
Ok so I made a small multithreded program in c++, when I compile it on one machine it works fine but when I try to run it on another machine it says "missing msvcp123D.dll".
I went looking around the forums and found some good info on this one. The solution was to create static links to the needed libs.
Project Properties -> General -> Use MFC in a Static lib
Project Properties -> Input -> additional dependencies -> ? now I would like to ask what libs do I need to add here in order to make this work on Windows 7 , 8, 8.1 machines
Thank you all for your time.
msvcp123D.dll is the DEBUG runtime. Build a release version and install the VC2013 redists on the target machines to get rid of this error.
Alternatively you can statically link the run time in which case you'll just need your own binaries (even if its a debug build).
Edit: To statically link the runtime right click the vcxproj file and go to properties, then under C/C++ code generation change "Multithreaded Release/Debug DLL" to "Multithreaded Release/Debug". The options with out "dll" in the name are the static versions.
I'm attempting to compile a release executable using vs2012 Express. However, whenever I try to run the .exe on other computers, I get a warning that I need msvcr110.dll. I could simply copy the dll over, but I'm looking for a more long term solution.
In my attempts to isolate what is causing the error, I have reverted back to a new c++ project using the default settings, except for changing the configuration to release in the configuration manager.
I've been trying to solve this on my own for over a week now without any progress, so any suggestions would be appreciated.
Link to the CRT statically. Choose "Multithreaded", and not the DLL option in the Runtime Library dropdown in the project properties.
In your project properties choose option Configuration Properties/C/C++/Code Generation/Runtime Library and pick option 'Multi-threaded (/MT)' (or 'Multi-threaded Debug (/MTd)' for your debug configuration).
For dynamically linked applications, the Visual C++ Redistributable for Visual Studio 2012 must be installed in target machines. Be sure to choose the architecture that matches your application.
Statically linking will obviously work, too, but I tend to classify this as a workaround.
When i use Visual Studio, my executables depends on microsoft redistributable package - the package that deploys MS's runtime DLLs. That is annoying to me. What disatwantages my executable would have if i would use MinGW?
I also want to try link with lib- avcodec/avformat, that are built by MinGW and i have no my own mind power to build them in VS from src.
In case of using MinGW you will depend on DLLs that are shipped with mingw. It is not big deal to change one vendor to another.
If you already have MS project, review possibility to statically link MS libraries (it is option is provided for some of VisualStudio projects on creation time in project options)
You can link everything statically with MinGW. Use the -static linker flag.
No need for redistributing any DLL's, but you have to make sure that in the c++, there's no exceptions being passed over DLL boundaries (so make sure every C++ library is linked statically in this case).
I have created a wn32 project with Visual Studio 2008 and Visual C++ language, it uses the ws2_32.lib library and then I compiled in Release mode.
It runs very good in the same computer, but when I copy the exe file to other computer (that doesn't have installed Visual Studio), it doesn't run.
The message I see is:
This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem.
But, if I compile my application using DEV C++, it generates a bigger executable (738KB) compared with the Visual Studio 2008 executable (9.5 KB). However, the DEV C++ executable runs in the other computer.
I have add the library ws2_32.lib to the linker properties of my project, in the Additional Dependencies field.
How can I fix it to work with Visual Studio 2008?
My code is the following: http://www.stan.com.mx/yupi/udpserver.cpp
The problem is almost certainly that the other computer does not have version 9 of the C++ CRT installed.
The default setting for compiling against the CRT in VS2008 is to dynamically link vs. statically linking. If you want to deploy your program with a real setup project you'll need to include the CRT redistributable.
However if you want to do an XCOPY deployment follow the steps on the following page.
http://msdn.microsoft.com/en-us/library/ms235291.aspx
Try installing the Visual C++ redistributables. If that doesn't work, use DependencyWalker to find out what DLLs are missing.
I agree with JaredPar. The application you build with VS2008 is using dynamic linking, whereas the DEV C++ is linking statically, hence the larger size and why one works and not the other.
However, if its a plain win32 application project you've got (and you don't want/need to distribute it with a setup), you may be able to get it to run on another machine without redistributing the CRT by getting VS2008 to link statically for you (if its just the standard lib you're missing). I don't have a copy of VS2008 to hand, so I'll describe how to do it in VS2005 and hopefully it'll translate across.
Bring up configuration properties for the project (right click the project name, then select "properties" from the menu)
Expand "Configuration Properties", then "C/C++", then click "Code Generation"
Under the "Runtime Library" item, for your particular configuration select the non-DLL version of the library i.e. for debug builds you want "Multi-threaded Debug (/MTd) and for release builds you want "Multi-threaded (/MT)"
Try and see if that works. You'll obviously get a much bigger final binary now the library is statically linked.
You may be missing an external dependency required by your program. Check the project settings to see if you are linking against MFC dynamically for example. You can also run Depends utility to check for missing dependencies.
I'm wondering how to make a release build that includes all necessary dll files into the .exe so the program can be run on a non-development machine without it having to install the microsoft redistributable on the target machine.
Without doing this you get the error message that the application configuration is not correct and to reinstall.
Choose Project -> Properties
Select Configuration -> General
In the box for how you should link MFC, choose to statically link it.
Choose Linker -> Input. Under Additional Dependencies, add any libraries you need your app to statically link in.
You need to set the run-time library (Under C/C++ -> Code Generation) for ALL projects to static linkage, which correlates to the following default building configurations:
Multithreaded Debug/Release
Singlethreaded Debug/Release
As opposed to the "DLL" versions of those libraries.
Even if you do that, depending on the libraries you're using, you might have to install a Merge Module/framework/etc. It depends on whether static LIB versions of your dependencies are available.
Be aware that Microsoft do not recommend that you static link the runtime into your project, as this prevents it from being serviced by windows update to fix critical security bugs. There are also potential problems if you are passing memory between your main .exe and .dll files as if each of these static links the runtime you can end up with malloc/free mismatch problems.
You can include the DLLs with the executable, without compiling them into the .exe and without running the redist tool - this is what I do and it seems to work fine.
The only fly in the ointment is that you need to include the files twice if you're distributing for a wide range of Windows versions - newer OSs need the files in manifest-defined directories, and older ones want all the files in the program directory.
You'd be looking to static link (as opposed to dynamically link)
I'm not sure how many of the MS redistributables statically link in.
If you are looking to find out which dll's your target machine is missing then use depends.exe which used to come with MSDev, but can also be found here. Testing this on a few target machines should tell you which dll's you need to package with your application.
You should use a static link and add all libraries you need under additional dependencies.