I am trying to compile qt, and am faced with two choices whether use MinGw or Visual Studio compiler? What is the difference between them, and are there any advantages/disadvantages of using one or the other?
They are both fine tools. The important thing to know is that they don't necessarily play well together. That is, as you link libraries together, they must all use the same tool chain. For this reason, in my opinion, it is better to use the Visual Studio compiler (MSVC), as it is the "first class citizen" on Windows; the others are treated somewhat as second class.
What I mean is that you can pretty much count on third party libraries being available in binary form using MSVC, or at least build instructions being available using MSVC. We had lots of problems with third-party libraries not being able to build in MinGW or having nonexistent build instructions and having to do a lot of manual Makefile editing, etc. You are much more likely to have things "just work" if using MSVC.
That is just our experience (we started with MinGW); your mileage may vary.
MinGW uses GCC, and GCC has one significant advantage to MSVC - it is portable. MSVC is limited to Microsoft platforms, GCC supports pretty much everything, including 8bit embedded CPUs. Meaning that you can use the same directives and compile extensions across different platforms.
Also, MinGW is compact, quick to install, and a version is even bundled with Qt. Unlike MSVC, which is not even available standalone, you have to install visual studio, which itself installs a bunch of garbage you don't need but can't opt out of.
UPDATE
It is now possible to get the MS compiler without VS, a.k.a MS Build Tools. Also, If you want to build chromium (a.k.a the QtWebEngine) for windows you have to use MSVC, that's a limitation imposed by google, as they only support building with the platform-native compiler.
Last but not least, you can get MSYS2, which has a repository with MinGW and a ton of ready to use static and dynamic libraries build for it, so you can avoid the arduous and often failure prone build process.
UPDATE
Just for the sake of reference, for VS build tools 2019, the C++ compiler alone takes up about 4.5 gigabytes of space, or about 8 if you just click "C++ build tools" and leave it at the default. For comparison, GCC 9.x is about 150 mb. In fact, the MSVC compiler alone is larger than the entire extensive collection of packages that I adopted for use throughout the years, plus their dependencies, for a total of over 200 packages. Additionally, I'd say MSYS had packages for about 98% of the libraries and tools I've found myself in need of, and those remaining 2% include libraries it had but were not configured in a way, suitable for my use case. And it goes without saying, the packet manager makes it trivial to keep versions up to date.
Related
TL;DR - The MS docs state that binary compatibility between VS2015 and VS2017 libs is one-way, while I'd assumed it is necessarily two-way. Where's the catch?
First, for background:
Any MSVC++ built libraries are officially binary compatible between VS2015 and VS2017.
Specifically, you can use your VS2015 C++ app with the MSVCRT140 version from 2017. (VCRedist backwards compat)
The official documentation site states a confusing restriction.
Background / related Questions:
Is Visual-C++-2017 binary compatible with VC++-2015?
Questions about "Binary Compatibility between Visual Studio 2015 and Visual Studio 2017"
Binary compatibility between VS2017 and VS2015
The confusing restriction I find is:
There are two exceptions to this rule. Binary compatibility is not guaranteed in these cases:
...
When consuming libraries built with a toolset whose version is greater than the toolset used to compile and link the application. For example, a program that is compiled and linked with compiler version 19.12 can consume libraries that are compiled with 19.0 up through 19.12.
This caveat is, IMHO, both technically sloppy and confusing. What would the technical reason be for that?
I say it's sloppy because it is incomplete, because the interface between an executable and a DLL is pretty syymetric, but this bullet only covers "the application".
Specifially, and assuming all modules are built against the dynamic CRT version and this dynamic CRT version is the newest version available, I see the following combinations where binary compat is an issue:
my_2017.exe <-> my_2015.dll -- seemingly supported
my_2015.exe <-> my_2017.dll-- seemingly unsupported
my_2017.exe <-> my_2015.dll <-> my_2017_x.dll -- what now, in which "direction" is this supported btw DLLs?
Since binary compat - purely from the binary/interface perspective - must run both ways, I don't quite see where we suddenly could get an incompatibility here: API calls can go both ways (callbacks etc.), objects "move" both ways, even the order of DLL loading can be mixed.
This is an important point IMHO, as it means the binary compatibility as stated is severly limited:
If my application want's to consume any VC14* compiled library, I "officially" still must make sure that my application is built with the "newest version".
On the other hand, if don't build an "application", but have a DLL, I can seemingly consume any other VC14* DLL and be compatible?
With the VCRedist, we have exactly the case that is seemingly unsupported, namely we are allowed to consume a VC2017 library (CRT in this case) from a 2015 app!
Question
So, why(!) is this limited in the way it is, and how does it relate to inter-dll dependencies and also the inverted(!) CRT-dll version requirement.
Microsoft has since updated their docs, the relevant section of the current version of https://learn.microsoft.com/en-us/cpp/porting/binary-compat-2015-2017 reads:
C++ Binary Compatibility between Visual Studio 2015 and Visual Studio 2019
...
When you mix binaries built with different supported versions of the MSVC toolset,
the Visual C++ redistributable that your application runs on cannot be older
than any of the toolset versions used
to build your app or any libraries it consumes.
The diff is at https://github.com/MicrosoftDocs/cpp-docs/commit/a505dccfb31eb49c2ffece4dabd24a0a61b1fcb3#diff-d488b4c71be450b2a39cdce495c229bf
There is no direct GitHub/MS-Docs issue for this, but this limitation makes a lot more sense: It just talks about the compatibility requirements of the redistributable, and requiring a VC runtime version that is at least as current as the newest module in use.
This, of course, can make sense, as this is not only pure binary compatibility.
Of course, what I said in the question still is valid: Any (old) VS2015 application must be compatible with the (new) VS2019 redistributable, so I guess all the interface surface that VCRedist-VC14.0 ever exposed should be binary compatible.
I have an installation of visual studio 2015 (french version). The installation itself take a lot of disk space. I have only C++ compiler installed without .net, C#, web and mobile developer toolkit.
Does anybody know what is the actual reason for too much disk space requirement compared to other C/C++ compiler toolkits (GCC, Clang).
another point:
Installing a language pack for english demands 4GB of disk space. Why it requires that much space where I am installing only a different language. I mean compiler executable remains same in this case. Just the internationalization parameters needs to be changed.
Is there any technical or commercial reasons to why Visual Studio do this.?
The installation itself take a lot of disk space. ... Does anybody know what is the actual reason for too much disk space requirement compared to other C/C++ compiler toolkits (GCC, Clang).
Because Visual Studio installs a heck of a lot more stuff than just a compiler toolkit like GCC or Clang. For example, it includes an IDE, an interactive debugger, a bunch of libraries, the source code for all of the included libraries, profiling and other tools, etc.
If you just want the compiler toolchain and not the IDE or anything else, download the standalone C++ build tools.
Or, for an earlier version of the build tools, just download the Windows SDK. (The build tools are no longer included starting with the Windows 8.1 SDK. Therefore, you'll need to get an older version, like the Windows 7 SDK.)
I would like to use C/C++ for coding my apps, but I need my apps running on all versions of Windows from XP to Win8, independently by any platforms, run time libraries and so on.
Briefly: What kind/type of C/C++ I suppose to use, be able to run my apps on every type of Windows without any additional installation, just default one. e.g Windows XP SP1
C++ can run on just about any OS, as long as you avoid (or, via conditional compilation, provide alternatives for) anything specific to one OS or version. Win32 code is almost all the same between versions; the main difference is added functionality in newer versions. Between Windows and, say Linux, though? Not so much. You kinda need to pick a platform, unless you want to either stick to text mode (which is pretty close between OSes, thanks to standards) or learn some whole other platform-neutral API like OpenGL, wxWidgets, GTK, etc.
As for which compiler to use, if you're sticking with Windows, I'd recommend Visual Studio. Microsoft has a free (Express) edition that will let you compile Win32 code or .net. (You'll need the paid version, or some playing around with the Platform SDK, to play with 64-bit though.) And the IDE isn't too bad either. If you just want a compiler, the Platform SDK has the same compilers VS has, and includes 64-bit support (and even a bunch of code samples and tools) as well.
As for being independent of any runtime libs: Every C++ compiler that's worth using has a runtime library. If you link statically against it, though, the parts you need will be embedded in your EXE. Alternatively, you have permission to distribute the runtime libs with your app (though you may need to install it via a package they provide, that you bundle together with your app...i forget how all that works).
All popular C++ compilers support XP up. You can statically link the runtime, or, for mingw, you can link against the runtime supplied with Windows.
Two things come to my mind whenever I revisit the subject of using Visual Studio's compiler and linker to build Windows drivers:
It is not officially supported. Indeed, the consensus all over the Internet is that the right way to build Windows drivers is to use the compiler, linker and BUILD tool included in the Windows Driver Kit. However, Visual Studio 2008 includes the /DRIVER linker option, which is described as follows: Use the /DRIVER linker option to build a Windows NT kernel mode driver. What does it do? Why was it included in Visual Studio if using it for building drivers is not recommended?
It works. I'm almost afraid to say this out loud lest I incur the wrath of the righteous kernel developers, but the truth of the matter is that drivers built with Visual Studio do work. We've been building them this way for years at my workplace, the produced binaries have been deployed on hundreds of machines, and there haven't been any problems. However, I am aware that the absense of evidence is not evidence of absense, and that the lack of any problems so far doesn't necessary mean that building drivers with VS is safe.
What really bothers me here is the lack of information. There are a few posts over the Internet from people who use VS to build their drivers, which invariably draw the same response - it is not supported, do not do it, integrate WDK with VS by means of a makefile project if you really want to use VS's IDE. However, I haven't found a single reply which points out a concrete reason why you shouldn't build drivers with VS.
So, does anyone know what would happen if you use VS to build your drivers? What could go wrong? Under what circumstances? I know that you have to set all compiler and linker options yourself, and it's allright, but what happens if I set them wrong? Will the driver fail to compile, or will it fail to link, or If it builds fine will it crash outright or only when the stars align right? Why would it do that, what causes it? Is there any reason to stop building our drivers with VS which has worked like a charm for years, apart from the fact that it is not officially supported? If it is not officially supported, why put the /DRIVER switch in VS?
The reason this is common-sense is because the resulting flaws can be subtle. Most of this has been cargo cult, though ... ever since there was an actual problem. And if I remember correctly that would have been before 2005 (i.e. the first DDKs at all containing a compiler). Correct me if I'm wrong.
Generally, I don't see a lot that speaks against using the VS compiler though. For the the linker you also have to set the proper subsystem value (i.e. none) and so on ... it's just tedious.
However, keep in mind that the WDK compilers and tools are usually ahead of those in the latest VS at any given time. Consider this: what the WDK contains is a close as you can get to what is used to build Windows itself. Hence the preference for the tools from the WDK.
Technically it can be done. But if you post to a newsgroup and mention the fact, don't be surprised if you first get to hear a lesson on that topic rather than your actual question ;)
If it is not officially supported, why put the /DRIVER switch in VS?
It's not a matter of putting the switch in to VS, it is a matter of taking it out.
The C++ compiler/linker that ship with WDK and VS are built from the same source base (perhaps from different branches and at different points in time, but the same source base), by the same team inside Microsoft. Could they configure their builds so that the /DRIVER switch doesn't appear in the linker delivered with VS? Sure. Is it worth the cost of maintaining a separate build configuration and checking that the right build variants are delivered with the WDK and VS, respectively? Probably not.
As to why it isn't officially supported in the first place... The expertise of validating a toolset for driver development lies within the Windows team, not the VS team. The last thing the Windows team wants to do is to be on the hook to qualify a release of VS for driver development (which Windows would ultimately have to help support, as well), when that release is on a schedule that doesn't line up with Windows.
Combine that with the fact that driver development is targeted at a relatively small audience, and building drivers through IDE opens up additional features and test scenarios, and it is very unsurprising to me that it is not officially supported.
I'm looking for a make system, along the lines of CMake or Bakefile, that supports the generation of Visual Studio project files and makefiles (targetting Linux) dual targeting x86 and x64 (in the same project/make file).
I've looked at CMake and Bakefile and they both appear to have limitations in this respect; they both appear to not support multiple targets (Bakefile doesn't even seem to support 64bit vcproj).
Are there any other tools, open source or paid, that may be suitable?
There's a (simple) patch for Bakefile that enables it -- you may be able to help with testing it.
Although it's a higher level tool and that you probably already know about it, I would propose SCons.
CMake can generate code multiple targets architectures (32 and 64 bit, say) on different platforms (win and linux, say). I can also use qmake (part of Qt) for this.