I've downloaded and compiled an open-source C++ application, Frhed.
When I run the version I've compiled, it demands MSVCR100 and few other dll files (part of Visual C++ redistributable). However, when I run the original precompiled Frhed executable, it runs without any C++ redistributable package installed.
Do I have to modify any compilation options in order to unlink the program from the C++ redistributable libraries?
The original program is probably statically linked, whereas you are trying to dynamically link your executable, which results in a smaller file, but a dependency on functions inside MSVCR100.dll (v10 of the Microsoft C Runtime Library), which would have been included inside the executable if you were statically linking.
To statically link DLLs, go into your project properties and change the build mode from MD to MT. In Visual Studio 2010/2012, that project property is C/C++ -> Code Generation -> Runtime Library.
The short answer is yes, the longer answer is, well, longer.
The library msvcr100.dll is the 10.0 version (i.e., Visual Studio 2010 version) of the DLL implementation of the C run-time which you probably requested by using the /MD compile option. To avoid using the dynamically linked version of the run-time you can use the /MT option instead and statically link the run-time.
Alternatively, you can redistribute msvcr100.dll (and other files) along with your program.
Related
I have an SFML, Visual Studio project that needs to be linked using the /MT option in the runtime library settings because I want to avoid having to install the microsoft redistributable to every computer that runs the program.
When I added sfml to the project, it appeared to work fine in its dynamic form. However, when I tried the program on another computer, it told me that I had missing visual studio dlls.
I understand that in order to link sfml statically to the project I would have to rebuild it with different runtime libraries. My question is why would it be able to correctly compile with sfml dynamically linked to the project and have the project set to /MT at the same time if it failed to statically link the necessary visual studio dlls to the project?
After discussions in the comments, we agreed on this:
It is not uncommon to link some libraries statically and still link dynamically to others, like the language runtime. So the compiler should not complain about this.
To get a single executable containing everything, the program must link all libraries statically and they must, in turn, also link statically to all their dependencies.
Otherwise, if we have one dynamic library, like SFML, that library will likely in turn link dynamically to the runtime library. And that will still require the runtime DLLs.
This is possible, you'll just have to build SFML yourself (which isn't that hard to do).
Just make sure that you set the CMake variable SFML_USE_STATIC_STD_LIBS to TRUE so SFML uses the static runtime, no matter whether you're actually creating static or shared libraries.
In short:
Clone the official repository.
Install CMake. (If you're using Visual Studio 2017, you can also directly open the source directory as a Folder, but setting the variables is a bit more tricky this way.)
Create a build directory, go there and run CMake: cmake -DSFML_USE_STATIC_STD_LIBS=TRUE -DCMAKE_INSTALL_PREFIX=C:/path/where/to/install/SFML C:/path/to/the/cloned/source/repository
Once done you'll find a Visual Studio solution and projects.
Just build the INSTALL project for the Debug/Release targets and you'll get your shared SFML using the static runtime.
I am using Visual Studio 2013 to develop c++ static libraries *.lib. I got a request to compile the library using Visual Studio 2010 compiler, however I do not have it installed on the developer machine.
When compiling dynamic library *.dll it is possible to use switch /MT that will pack the C runtime into dll. The dynamic library thus becomes larger. However, when I use the /MT switch the static library becomes smaller (5MB -> 4.9MB) which is against what I would expect.
Question:
1. Can I build static library in Visual Studio 2013, so that it can be later used by Visual Studio 2010 compiler?
2. Is the /MT switch the right way to do it?
Static libraries are in general only compatible with the toolset that built them. This is especially true of any use of the Standard C++ Library / STL, which is why newer versions of VS have the _MSC_VER stamp embedded for any use of the STL headers that will generate link-time errors if you attempt to mix them.
It is also important that static libraries be built with the same CRT settings (/MT, /MD, /MTd, /MDd) as the project that is consuming them.
DLLs using C or COM exports using the CRT DLL are really the only 'stable' library that can be mixed with different versions of the compiler safely.
Otherwise, you should obtain the toolset for every version you want to support and build all desired flavors of the .lib.
My friend wanted me to make him this program and he is not very tech savvy. How can I make the .exe run without making him download anything extra? It was coded in C++ on Visual Studio.
If your program uses anything from the standard library, it will need the Visual C++ runtime library, which is typically loaded from the library DLLs (something like msvcr110.dll).
However you can instruct the compiler (the linker, rather) to include (I do not mean #include-ing the header file) the library as part of your executable (exe file). (I guess you thought of ISO because an archive file would include all the necessary DLLs) According to https://msdn.microsoft.com/en-us/library/2kzt1wy3.aspx, use the /MT compiler option will cause the "multithreaded, static version" of the Visual C++ runtime library (which is the library in pre-compiled code) to be included in your program during linking (in contrast to the default /MD option, which only causes code that helps your program link to the main library DLL to be included).
Correction: The program will be larger, but since the linker does not actually add everything to the output program, the size of the output file depends on what the program uses. Microsoft Visual Studio ~ C/C++ Runtime Library ~ Static/dynamic linking This might be helpful. (If you are interested, look into Program Files (x86)\Microsoft Visual Studio 12.0\VC\lib (don't forget to replace the version number).)
Go to project settings -> configuration properties -> C/C++ -> code generation and set runtime library to Multi-threaded (MT).
Correction: it seems directly setting the compiler flag will work even with the default /MD or /MDd flag left in the command line.
EDIT: be sure to clean the solution (build -> clean solution) after applying these settings. Otherwise the linker may still try to use the old files.
I complied boost library by using vc 12 but my visual studio has vc 11. when I try to run boost sample program which is used boost (c++ library ) visual studio 2013 shows cannot open file 'libboost_regex-vc110-mt-gd-1_54.lib my libray path -(..\boost_1_54_0 2\stage\lib) im having libboost_regex-vc120-mt-gd-1_54 . think that issue I can solve by changing visual studio complier vc11 to vc12. how do I do that please help me.
Unless there is compiler or OS related dependency, you can solve it by linking with appropriate library. Check the setting of your project. Where, it was expecting vc110 library, change it to corresponding vc120 library.
If it does not work (because of some other issues like compiler specific problem, platform specific problem, or duplicate symbols as it was linked with different C runtime library), you can try the following:
Rebuild boost but with dynamic CRT library (instead of static library) (check /MD or /MT option). In this way, you need not to change either of compiler.
If nothing works, build both application and library using same compiler.
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).