I'm doing some experiments with Mingw-w64 and it works great compiling regular C code, linking to the Windows system MSVCRT.DLL C library. But, if I compile C++ code, then mingw's g++ links to what looks like the GNU libstdc++ library. Why? This doesn't happen with regular C binaries. I see commerical Windows software all the time including the Microsoft "C++ redist" package, which I guess matches the version of Visual C++ they use to develop their software. So it seems like there's actually no C++ library by default on Windows. I'd like to use the "system" C++ library and not use the GNU one if possible to reduce the size of the binaries mingw is compiling. But, I also don't want a separate C++ redistributable that needs to be installed. Am I stuck with the GNU library?
MinGW/MinGW-w64 build do use system standard libraries, that are part of Windows.
Visual C++ redistributable and runtime packages are only needed when sources are compiled with MSVC.
If your MinGW/MinGW-w64 build isn't statically linked you may need to ship libstd DLL files, but you can just put them in the same place as your .exe and/or .dll files, along with any other dependancy .dll files.
I actually love the fact that MinGW/MinGW-w64 builds don't need Visual C++ redistributable for several reasons:
The user doesn't need to install yet another Visual C++ redistributable.
The binaries are compact and don't depend on other Microsoft libraries except the ones in the operating system, which increases the chance of your software running well on different Windows versions.
Install (and uninstall) instructions (or installer code) are easier as the Visual C++ redistributable dependancy doesn't need to be installed. In fact you can even run your software as a portable app without installer.
Related
I'm trying to compile a C/C++ library under msys2. The problem is, the library requires Windows Runtime Library (WRL). And maybe more parts of Visual C++ Redistributable libraries. However I did not get that far in compilation process.
I found this thread about MSYS2 and WRL which suggests, that WRL is not supported yet. But its from late 2013. Maybe things have changed since.
Is any chance to make Visual C++ libraries (and headers) work with MSYS2?
Thank you
I've stumbled upon the issues with having the wrong MSVC run-time when linking or running apps written in C or C++. Because of that, I try to be exact on using the correct versions.
I see that the SDL (Simple DirectMedia Layer) library is pre-compiled with MSVCRT, which AFAIK is compiled with MSVC 4.2 to 6.0. Still, that pre-compiled library works fine with my apps compiled with the much later Visual Studio 2015 v14.
How come there are no issue with linking old MSVCRT with MSVCR140, e.g. SDL?
Is there a way to make a library be compatible with any greater Visual Studio compiler?
How is this solved with using other compilers, e.g. GCC or even on Linux or Mac?
Because the, let's call them vintage, runtimes are used so widely they're always there. But more recent runtimes, used by a newer Visual C++, might not be automatically present. Also, Visual C++ standardised on a single runtime library for some time, ensuring backwards compatibility with existing applications. Somewhere around Visual Studio 2012 this was dropped in favor of version specific runtimes.
You need to package your application into an installer that also installs the necessary runtime (or runtimes if you require more than one).
Linux applications are packaged (RPM, YUM etc.) with dependencies on runtime components. Basicaly the same as a Windows installer. Dependencies are either part of the package or satified by the distro. Linux shared libraries are versioned, multiple versions can be installed side-by-side and an applications can link against specific versions if required.
I know that I have to distribute C / C++ runtime libraries along with my project. I am just wondering why Microsoft does not do that for us? I know that there is Visual Studio 6.0 runtime included in Windows but why there is no new one?
If somebody could give me a link to some explanation article. I am trying to google that without success for a while.
There is a C runtime included with Windows, msvcrt.dll. The MinGW gcc variation uses that library as its base runtime. Microsoft also builds programs that link to that runtime (for example, the programs that are part of the Windows installation).
While the msvcrt.dll that is part of Windows has the same name as the runtime DLL from VC6, it's not necessarily the VC6 runtime. Each new version of Windows has added functions to the msvcrt.dll and probably fixed some bugs.
The WDK used to include build configurations to link to msvcrt.dll (it looks like the last version of the WDK to support this was WDK 7.1). These build configurations also included some compatibility shims, such as msvcrt_win2003.obj, that allow a program built with such a configuration to run against the msvcrt.dll libraries included with older versions of Windows - adding support for newer exception handling and some newer APIs, for example.
I suspect there are various reasons that MS prefers that 3rd party programs link to runtimes that are not part of the Windows system files. A couple possible reasons:
it helps ensure that the 3rd party programs are not broken by a Windows update that includes a newer version of msvcrt.dll.
it helps ensure that 3rd party programs will run against the runtime DLLs that they were tested against (since presumably the 3rd party program's installer also makes certain that the appropriate MSVC redistributable runtime is installed).
Is it possible to develop in C/C++ for windows and not to link against the msvcr100.dll?
I understand that this is the standard c library for windows, but I was wondering how all the programs on my computer could run if I hadn't Visual Studio or the Redistributable package installed?
Right-click your project in the Solution Explorer window, Properties, C/C++, Code Generation, Runtime Library setting. Change it to /MTd. Repeat for the Release configuration, pick /MT
You will now link the static version of the CRT, any functions you use get directly linked into your EXE instead of getting them from msvcr100.dll at runtime. So you no longer have the requirement to deploy the DLL along with your program.
Avoid using this option if you create your own DLLs. It then gets to be important that those DLLs and the EXE use the exact same CRT so they'll all share the same CRT state and the same heap. Because if they don't then you'll have nasty problems with passing C++ objects or pointers that need to be released from one chunk of code to another. An AccessViolation if you are lucky, a memory leak if you are not.
If you restrict your project to use only C programming language/library, then you can
only link against MSVCRT.lib which is completely baked in any Windows version since Windows XP SP3.
It means, that rather than dependency on MSVCR100.DLL (or any other Visual Studio DLL), you can only link against the standard C functions in MSVCRT. By the way, this technique is used in CoApp project developed under umbrella of Microsoft, so I'd consider it as a good pratice in such cases as yours.
Simply, download Windows DDK and link only against $(DDKInstallPath)lib\Crt\$(DDKPlatform)\msvcrt.lib
On Windows, I doubt it's possible to create a non-trivial program that doesn't use the CRT in some way.
It is possile to use the CRT without linking to msvcrXXX.dll -- simply link to the static libs instead. But to address your question:
how all the programs on my computer could run if I hadn't Visual
Studio or the Redistributable package installed?
If the programs on your PC were linked to msvcrtxxx.dll, then they couldn't. Sinmply, the redist that a particular program needed was already installed on your PC before you even came along, probably. Or at least, the parts of the redist needed by the program.
I have written a game that uses GLUT, OpenGL and FMOD. The problem is that the binary won't run, unless Visual Studio 2008 is installed on the computer.
Why is this?
Most likely you're linking with DLL versions of the C/C++ runtime. Go to project properties -> C++ -> Code Generation, and set Runtime Library to not be one of "DLL" kinds.
Alternatively, you can link to DLL runtimes, but then you have to redistribute the runtime with your application.
MSDN has more information on various aspects of C++ application deployment: http://msdn.microsoft.com/en-us/library/zebw5zk9.aspx
Also, Dependency Walker (depends.exe) will show what libraries your executable depends on. It ships with some versions of Visual Studio as well.
You mean why is Microsoft Visual C++ 2008 Redistributable Package (x86) needed?
This package installs runtime
components of C Runtime (CRT),
Standard C++, ATL, MFC, OpenMP and
MSDIA libraries. For libraries that
support side-by-side deployment model
(CRT, SCL, ATL, MFC, OpenMP) they are
installed into the native assembly
cache, also called WinSxS folder, on
versions of Windows operating system
that support side-by-side assemblies.
Because they are not installed on all Windows by default, especially the ones that shipped before VS 2008.
Even for
cout << "Hello, World" << endl;
You need a library, which in this case the Standard C++ library.
Welcome to the wonderful world of application deployment.
Run the tool depends on your executable and it will tell you which DLLs you need to also copy along with your EXE.
This program can help you find what dlls (if any) are missing on the the computer that it won't run on
Only the release versions of the C runtime and the C++ standard library dlls are installed with Windows by default. Installing Visual Studio will additionally install the debug versions.
Make sure the version you're deploying is built entirely in release mode.
Try compiling in release mode, and make sure that all required DLLs are installed on the target machine. It works for me.
Do you have dependencies on debug libraries?