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.
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've written a game using OpenGL, GLFW, C/C++. I use third party libraries like SOIL and irrKlang. I use Microsoft Visual 2015. Both the debug and release version run ok from visual studio. In properties -> C++ -> Code Generation-> Runtime Library I selected /MDd. I did try other settings but the release version wouldn't work with any other. All of my .dll are saved in the release and debug folders.
However, when I go to my release folder and copy and paste the .exe found there, onto my desktop,it no longer runs. I keep getting a message that says the irrKlang.dll is missing. Could someone please explain how to get a standalone .exe of my game up and running?
Two things here. First, the .exe is the executable which contains the entry point of your application. So this is indeed the first piece you need. However, your application is allowed to depend on code that's not linked into it statically, but rather dynamically -- such dynamically linked code is only loaded at runtime. These runtime libraries of code are called DLLs ("dynamically linked libraries").
If your application depends on a DLL, it will look for that DLL while it's running. If it doesn't find it, you'll see that message box about a missing DLL. So, you need to copy not only the .exe file, but all the .dlls it depends on (and that they depend on) too. Note that your application links against many default system DLLs, e.g. kernel32, but these don't need to be copied next to the .exe because they're always present in the system search path.
Now, the second part. If you want to run your application on a PC that doesn't have Visual Studio installed, you need to make sure that computer has the C/C++ runtimes that the VS2015 toolchain automatically links against installed. These are not DLLs that you copy by hand; rather, there is a redistributable installer for them which installs them globally on the PC for all applications. You can ship this with your own installer.
For this to work, you want to be linking with just /MD in Release (the debug CRT is for debugging only, and is only installed when Visual Studio is installed -- it's not meant to run outside your PC).
This statement:
"Both the debug and release version run ok from visual studio. In properties -> C++ -> Code Generation-> Runtime Library I selected /MDd. I did try other settings but the release version wouldn't work with any other."
Leads me to believe that maybe you don't have a release version of one of your third party libraries.
/MDd causes your application to use the debug version of the MS runtime, which means that something in your project is being built with or as a debug version.
I use the 'depends.exe' application to see the dependencies of my executables and DLLs. It used to be provided directly by Microsoft, but now seems to be supported via a third party. Older SDKs will have it.
http://www.dependencywalker.com/
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.