GCC runtime libraries vs Microsoft Visual C++ runtime redistributables

19
votes

Could anyone shed some light on C++ library versioning and distribution of

  • GCC library (libgcc, libstdc++,..?)
  • Microsoft Visual C++ runtime libraries (6.0, 2005, 2008, 2010, 2012, 2013, 2015,....)

With my limited exposure to GCC programming, I have never seen C++ runtime libraries being distributed along with program. That is often the case with MS Windows programs.

Can a relatively old linux system run a newer C++14 program (which is compiled on a newer system and then copied over to old system)?

Do GCC programmers distribute runtime libraries along with programs? If no, Why do Windows programs distribute them? How GCC distributions ensure that a C++ program always works when installed?

What about the frameworks such as Qt, How does Qt handle versioning and distribution on Linux and Windows? Does Qt also distribute runtimes for different versions?

May be it has to do with platform, how Linux is designed vs How Windows is designed.

What is so fundamentally different in approaches GCC & MS Windows take?

1
c++cqtvisual-c++gcc
The "fundamental difference" is that gcc tries to preserve the binary interface between releases. Microsoft delivers a brand new set of libraries with each release. Both approaches have their advantages and limitations. For example, how hard is it to introduce changes that breaks the interface? How often will the users have to install new versions? – Bo Persson
GCC had many bugs, I am sure many of them would be at interface level and often it is required to change the interface to address them, How would you "preserve" the binary interface between releases . – user1
@BoPersson If I'm not mistaken, Microsoft and linux approaches are much more similar than that. The MSVC runtime DLLs also have different versions with the same interface and within the same "release", that are distributed with patches. And linux also have a "release" versionning that can break the interface, with multiple SO files in the system. – ElderBug
@user1 Typically on linux, your binary will not work as the proper runtime does not exist, and it is non trivial to install it. On windows you can make it work if you install the proper runtime redistributable. – nos
@rubenvb Sure, and that was the backwards compatibility. By large, things work if you compile your binary on an older version of the distro, and try to run it on a newer distro. The same goes for windows - compile your binary to an older runtime, and newer windows versions will have that old runtime installed, or you can trivially install it. The question here though, is to run newer binaries on older systems. In which case the new runtime does not exist on that old system, and installing the new runtime on an older system is non-trivial. – nos

1 Answers

12
votes

GCC's runtime libraries, like GNU's C library, provide a stable binary interface (small footnote: GCC 5.1 kind of blew this up, due to new C++ features that had to be implemented). Microsoft's libraries don't, and each little version difference may and probably will break the ABI (application binary interface). Additionally, Microsoft compilers change their ABI with version increments as well, making it a bad idea to combine code built by different versions of their tools. Also here, GCC maintains a strict ABI, which makes object code perfectly compatible (if no ABI breaking codegen options are given of course).

This ABI consists of object size and layout, which a compiler uses when generating code. Therefore running code built against one version but using a different version at runtime may produce unexpected results because the memory layout and use is just different.

GNU/Linux is quite strong in this regard, and is generally able to maintain strong backwards compatibility. As long as the compiled program was compiled against an older version of the library, it will run perfectly if loaded with a newer version that a user has installed. The same story goes for Qt, which only breaks ABI between major version numbers (Qt 4 and Qt 5 cannot be loaded at runtime interchangeable).

There are some small exceptions, GCC 5's libstdc++ being a big problem there. I know of no big glibc ABI breakages though. The new Microsoft Universal CRT attempts to solve this issue, by providing a stable C runtime interface and as the story would have us believe, provide a glibc style library ABI stability. This UCRT is available for Windows Vista and up, but applications need to be compiled specifically against this. The first version of VS that has this capability, is VS2015.