How do you tell Visual C++ Express 2008 to statically link runtime libraries instead of dynamically? My exes do not currently run on computers w/o some sort of VS installed and I would love to change that. :)
Sorry, I do not have VC++ Express to test, but in Standard edition I use Project Properties -> Configuration Properties -> C/C++ -> Code Generation -> Runtime Library. Dll and Dll Debug are for dynamic linking.
Are you 100% sure that you want to do this? Please consider that if you do and there is a security vulnerability found in the runtime library, Microsoft will not be able to patch your application via Windows Update.
Another solution is to package the Visual C++ Runtime Redistributable with your application. It installs very fast and does not require Visual Studio. It is also important to note that you should not distribute code linked against the debug runtime libraries as those do require Visual Studio. See this blog post for more information on packaging the redistributable.
EDIT: With that said, it's up to you. My point is simply that you should not disregard dynamic linking based solely on the idea that users must have "some sort of VS installed", which is not true.
See the answer to this question: How do I make a fully statically linked .exe with Visual Studio Express 2005 ?. It's for VS2005 Express but the answer still holds.
For the C-runtime go to the project
settings, choose C/C++ then 'Code
Generation'. Change the 'runtime
library' setting to 'multithreaded'
instead of 'multithreaded dll'.
If you are using any other libraries
you may need to tell the linker to
ignore the dynamically linked CRT
explicitly.
You can install the C runtime redist on the target machine and you're executable would run there as well with dynamically linked C runtime.
(Oh sorry, that had already been mentioned).
Related
I'm trying to make a binary that can be run on any windows machine without the visual c++ stuff installed (I'm assuming that's what MSVCP120D.dll is however my searching was not very fruitful as to what this actually is). I made a game for an assignment and wanted to have other people (non-devs without VS stuff installed), help me test it but they kept getting errors saying that the above dll is missing. I'm not using any Visual C++ stuff and have the /Za flag set to ensure that it's just ANSI C++. Does Visual Studio support compiling ANSI C++ and if so how do I go about making it not use Visual C++ stuff, if it doesn't support this what compiler should I use?
As you can see here, the MSVCP DLL is the platform's implementation of the C++ Standard Library. In short what that means is you cannot distribute your application without needing the "stuff" that these libraries provide. All compilers regardless of platform would need some kind of implementation of the Standard Library. Typically this is distributed in the form of libraries.
However you can distribute your application so that the "stuff" is built in to your program directly, rather than being shipped in a separate DLL. In order to do this, you must statically link your application to the Standard Library.
There are a few ways to accomplish this. One way is in Project Settings. In "Project" > "Configuration Properties" > "C/C++ Code Generation" > "Runtime Library", choose "Multithreaded (/MT)" as opposed to "Mutithreaded (Static)".
By the way, the "D" in "MSVCP120D.dll" you mentioned above means "Debug." This means that you are trying to distribute a debug build of your program. You should (almost) never do this. Distribute release builds instead.
You have three options (in the order I'd recommend):
Don't statically link, instead get people that want to run your game install the visual studio re-distributable package. 32-bit VC 2010 version here: http://www.microsoft.com/en-us/download/details.aspx?id=5555
Statically link the CRT (the dll you don't want to require at runtime) see here for details: How do I make a fully statically linked .exe with Visual Studio Express 2005?
Build an app that doesn't even use the CRT at all. Here you will have to implement your own operator new that calls HeapAlloc(), and operator delete that calls HeapFree(), its an interesting challenge ;). To do this you tell the linker to ignore all default libs.
Build with the static runtime libraries rather than the DLL versions.
Go to Properties, C/C++, Code Generation, Runtime Library and select /MTd or /MT rather than the /MDd and /MD options.
Configure your project to link against the runtime statically rather than dynamically.
First of all the D on the end of the name indicated a debug build. If you make a release build then it will need it without the D. This is important because microsoft do not allow the debug libraries to be distributed without visual studio.
The machine you are trying to run the program on may already have the release runtime installed as lots of programs use it. If not then install http://www.microsoft.com/en-us/download/details.aspx?id=30679 on the machine ( I think that's the right one but can't check at the moment)
You'll want static linking, that 'builds in' the external library calls into your binary. It does have the added affect of larger binary file, but in your case that doesn't sound like that big of a deal.
On a side note, MSVCP120D.dll is the Microsoft Visual C++ 12 debug DLL (dynamic link library) that contains all of debug C++ libaries (i.e. iostream, string, etc). That library is what you would be 'baking in' to your final binary.
Hope that helps.
I encountered this error when I tried to execute my exe on a different machine that had a newer version of Visual Studio on it. You need to change the project properties and re compile in order for this to go away.
To do this:
Open up solution that you are trying to run
Right click on the Project file - > Properties
In Configuration Properties and General, Ensure Platform Toolset is configured to be the correct compiler on your machine. If it is not correct, it should give a message next to it saying that it's not installed.
Build and run the code again and you should no longer get the issue.
I work on the optimization algorithm so the performance really matters. The algorithm is about 8 times faster when compiled in VS 2010 compared to VS 2008. Googling shows that it is not my fault (see e.g. https://stackoverflow.com/a/5560184/890355). The problem is that the final project must be built under VS 2008.
The solution I tend to is to built my algorithm as DLL in VS 2010 and then link it to the main project. Is it possible to use VC++ 2010 run-time libraries with my DLL under VS 2008? If so, what is the least painful way to do it?
Any other ideas?
Thanks.
The runtimes are not an issue. Nothing stops you from linking your DLL against the VC2010 runtime and then using that DLL in other projects. It doesn't matter if those projects are built using Visual C++ 2008 or any other language.
The tricky part is designing the DLL interface. Simply exporting some C++ classes is risky since it exposes you to incompatibilities between the different compilers. I think your best bet would be to either expose a C-style interface or use COM. I think COM is the best approach, but if you're unfamiliar with the technology, then a C-style interface will work fine. (COM could also be over-kill if the interface is simple.)
If you ask for any other way to combine 2008 and 2010 libraries in one executable other than moving 2010 part outside into a DLL, than the answer is probably "there is no other easy way to achieve this".
But if you don't want to "VC++ 2010 run-time libraries ... under VS 2008" (that is building against 2010 libraries in old 2008 IDE), but "use a 2010-compiled DLL in your 2008-compiled program", it is perfectly possible.
The easiest way, as we do it in our projects, is to build (both .exe and DLL) against statically linked standard libraries (MFC, if you use it) and then use LoadLibrary in your .exe to load the DLL. In the DLL you can export (_declspec (dllexport)) a function (preferably inside extern "C" {} guards) and use it in the .exe through GetProcAddress.
Static linkage and explicit loading save you from a lot of inconsistency bugs caused by different runtimes.
If you are worried about DLL loading and function calling costs, you can try to make these calls as rare as possible (maybe by moving not only the algorithm, but also some more high-level logics into the DLL). See this issie too.
And you can build all your code in one IDE (2010) using native multitargeting (however you will still need to build you main app and DLL separately against v9 and v10 libraries respectively).
You can if you're careful, and the MS documentation provides some hints. I have answered this question before here:
Wondering if the lower version of visual studio can use the dll built using higher version of visual studio?
I'm developing an application in Visual Studio 2010. The debug and release executable works fine on my PC, but when I try to run it on another PC< i get the MSVCR100.dll not found error.
The problem is described here:
http://www.rhyous.com/2010/09/16/avoiding-the-msvcr100-dll-or-msvcr100d-dll/
Searching on the web, reveals that you need to have the Visual C++ redistributable installed.
Is there a way to build the project so that the VC++ redistributable is not required ?
As noted in the page you linked, you can choose to statically build the libraries into your app, which guarantees they are always included. This is done in the project's properties -> C/C++ -> Code Generation -> Runtime Libraries (select multi-threaded or debug, without DLL).
If you don't want to statically link these, you can include the runtime DLLs with your program; this is useful for sharing a particular version between your modules and only yours, but installing the proper redistributable (and allowing upgrades, for security reasons, etc) is much preferred.
When possible, you should use the DLL from the system, to allow future security patches to apply to your program. The redistributable is a few MB and compatible with a variety of OS versions, so asking users to install it or even including it in your installer is not usually a problem.
To avoid using them entirely is perhaps possible, but slightly less feasible. You would have to avoid any code they provide, and MSVCR is the equivalent of libc; most programs use features from it and it's a standard part of the system.
Yes, you can links CRT statically (check project settings). But it will cause bigger executable size.
it's been a long while since I've used VS 2010 and C++, and as I'm getting back to using it, I'm running into the same problems that plagued me last year: the exe's that I compile do not run well on older machines that do not have the correct C++ runtimes. I do not even know what link to give them, and I told them to install this after they had an error that said "The program can't start because MSVCR100.dll is missing from your computer. Try Reinstalling the program to fix this problem. Click OK to close the application."). So I went in and set the code generation to /MT and disabled quite a few options, and tried messing around with lots of options, but still the same result.
My question is: Is there a list of complete VS 2010 C++ distributables that I can just give and tell them to install so all of the C++ programs I compile on my VS 2010 will work on Windows XP, or even better, a way to general a standalone exe that contains all it needs to work, and does not rely on DLLs? I'm thinking like linking to a library that has everything the exe references. If it helps, I'm building for both x64 and x86.
P.S. What's up with the manifest file, should I include it or not?
The easiest thing to do is to just install the VC++ Redistributable Package. It has both x86 and x64 versions.
Firstly, before I actually give you the detail:
Warning
If you do this, things will be bad for two reasons:
If there are security or other bugs in the MSVC runtimes, and you take this approach, they're baked into your app which means you need to re-distribute. DLLs are preferred because theoretically people use system update which means any errors get fixed.
Everything else you compile into your exe also needs to do this. If you don't, you end up with two versions of the code and whatever you're using won't link.
One possible solution is to bake the MSVC runtime into your application, by using the cl.exe option (C/C++ compiler settings) /MT which means multi-threaded version of the C/C++ runtime linked statically. As I said, if you try to link against something that is linked itself dynamically to the runtime, you're going to end up in a mess. Also, as I said, this represents an additional security risk factor, so bear that in mind.
The other options are to write an installer that can either download the appropriate runtime, or include the DLL needed.
If you're using some feature of the runtime that exceeds a certain version of Windows (generic statement, but it does happen) then you should be able to use the Windows SDK to target various versions of Windows using appropriate C runtimes.
http://www.microsoft.com/downloads/en/details.aspx?FamilyID=a7b7a05e-6de6-4d3a-a423-37bf0912db84
google text: visual studio c++ redist
Do not statically link to the runtime; specifically don't do so if you're using any kind of dll for other purposes. It introduces all kinds of bogus problems wrt heap management that you probably don't want to mess with.
Open the properties dialog for your project and select Configuration Properties | C/C++ | Code Generation. The default setting is Multi-threaded DLL. Change that to Multi-threaded and you'll be building and .EXE with the run-time statically linked in. Don't forget to do the same for the debug version.
If you're using MFC or ATL, you will need to navigate to Configuration Properties | General and set "Use of MFC" or "Use of ATL" to link statically as well.
NB: If you link the runtime statically, you must make sure that any other library you're linking in also links it in statically. Otherwise you'll wind up with two copies of the runtime in memory, each with its own heap and bad things will happen when code using one runtime tries to free an object allocated by the other runtime.
This previous answer should hold true for VS2010. I still build with VS2005, but all my apps use the static CRT for the sole reason of being able to run across old and newer machines alike.
I use MSVS 2010 and MSVC++E 2010 to build my applications in C++ and I've notice a lot of my friends (who test my apps on their PCs) don't have the Microsoft C++ runtime library installed on their computers. I've started including the Microsoft C++ redistributable package with my apps, but this seems unnecessary. Would I be able to instead include the libraries in my executable directory? I know that one of the libraries used is msvcr100.dll, but are there also others I need to include? Or is the redistro my best option?
in your project options, for code generation, you can choose the STATICally linked libraries instead of the DLL versions. That eliminates the need for an external dependency like this, at the cost of a larger EXE.
You don't necessarily need to HAVE to have the runtime library within your executable directory, you may use a Manifest File that has a relative path which points to runtime if you wish. But yes, you can include the libraries within the install of your application.
I think we lug around the msvcr as well as the msvcrt and the msvcp DLLs which now that I'm writing that out, might be a bit overkill.
When you build your application to a static runtime, you don't need to distribute the runtime dlls.
Otherwise you have to include the Microsoft runtime.
Links to runtime installers for Visual Studio 2010
Compiling your project with /MT solves the distribution problem. Be careful though, it can get you in trouble when you use DLLs. They will have their own memory allocator. If they export a function that exposes a pointer or a C++ object that needs to be released by the client code then you'll have a very hard to diagnose memory leak on your hands. Very easy to do, just return an std::string for example.
Anyhoo, the setting is found by right-clicking the project in the Solution Explorer window, Properties, C/C++, Code generation, Runtime Library setting.
Also note that VS2010 supports local deployment. Just put the msvcr100.dll file in the same directory as your EXE. You also need msvcp100.dll if you use STL or iostreams.