I created a DLL in VS2010 and used "Multithreaded" under C/C++->Code generation->Runtime library.
Now I wondered what the difference between "Multithreaded" and "Multithreaded-DLL" is.
The multithreaded option will link the CRT statically, whereas multithreaded DLL will link to a dynamic library.
With the former option, you'll get a larger binary, but you won't have to install Visual Studio redistributables everywhere you use it.
Related
Is there a way to build a static library without specifying the version of C/C++ runtime?
I'm using Visual Studio 2017 to build a static lib, and I have to specify a version for "Runtime Library" in the "Code Generation" option page (\MD or \MT). If I choose one version and the application using my lib chooses another, Visual Studio will spit out the error: mismatch detected for 'RuntimeLibrary': value 'MD_DynamicRelease' doesn't match value 'MT_StaticRelease'.
I know, when building an EXE, I can use the linker switch \NODEFAULTLIB to not include C/C++ runtime, but I'm building a static lib here which doesn't even have the Linker option page in its Properties window.
It seems that Simple DirectMedia Layer found a way to do.
Update: I later realized that I could actually turn on \NODEFAULTLIB switch in the Librarian option page in the static lib's Properties window.
You do it by NOT using any Runtime libraries. If you don't use any of the runtime libraries then the "Code Generation" option is meaningless as the runtime stubs are not pulled into obj file.
SDL basically say this on there web site:
On Windows, SDL does not depend on a C runtime at all, not even for
malloc().
As soon as you use any system include supplied by Microsoft VS then you are using there runtime library.
So if you only use the Windows SDK and the API supplied by the Win32 API then you don't need the VC runtime.
If you build a static library, it refers to your own library and not to the application as a whole. If you want to distribute the application, it just means that you will not need to distribute a separate dll. So do not set NODEFAULTLIB.
If you run the application on a machine where there is no Visual Studio 2017 installed, you might get an error message. The missing dlls are system libraries that are needed to run vs applications that are compiled with VS2017. You can get the missing libraries from: https://support.microsoft.com/en-gb/help/2977003/the-latest-supported-visual-c-downloads (this link is not guaranteed to be correct in the future). The redistributable dlls can be distributed freely. They are called vc_redist.x86.exe and vc_redist.x64.exe. Choose vc_redist.x86.exe if you have compiled you code for 32-bits. It does not refer to the machine on which the app is run.
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.
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'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.
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.