libcxx on MSVC6.0 runtime


After some wrangling, I’ve managed to get libcxx running, linking against the MSVC 6.0 runtime library (yes… from 1998). Right now, libcxx only supports MSVC 14.0 (2015) and above, presumably because the standard library did not have complete C99 support. I’d like to possibly contribute these changes, but I have a couple of questions.

  1. Would there be any interest in these patches, and would there be any chance of getting them merged since it would not be standards-compliant (due to missing C99+ functions in the runtime)?
  2. If so, what would be the proper way of handling the missing functions? Right now, I have solved the missing function declarations by declaring them in a “shim” header I created outside libcxx. Obviously, that’s a less than ideal solution. Instead, would wrapping the missing functions with a preprocessor if be acceptable? This would break standards compatibility when targeting MSVC 13.0 and below. Here’s an example:

using ::vfscanf;
using ::vsscanf;


What’s the motivation here? Is it classic MinGW compatibility (since that still uses msvcrt.dll, as far as I know), or something else?

I’d like to understand what’s the motivation for this work and what value it adds to the users of libc++. I can’t say I’m thrilled with supporting a runtime library from 1998.


We are not supporting this library.

(forwarding this one to the mailing list, since it seems to have gotten dropped)

It’s possible to deploy the Universal CRT to earlier Windows versions (including Windows 7), correct? Would that work instead?

Windows 7 supports the Universal CRT. It doesn’t come preinstalled on the system. I personally think that it is fine to require users to install a C-runtime on windows as part of an install… it’s just the price of doing business on that platform. (alternatively, you can statically link in the Universal CRT).

To be honest and clear. It’s a misnomer to say libc++ “supports” any Windows configuration at the moment.
The CI coverage we have is always red and needs a lot of love to get green [1].

Before we commit to supporting version X of vcruntime, we should get everything passing with the most recent version.
Only then can we evaluate the cost of backporting support.


As you’re probably aware, the runtime situation on Windows has been a real mess prior to Universal CRT. Many projects have dependency trees that force them to stay on a particular MSVC version – some projects are still using MSVC 2010 and earlier! Since Clang has quite expansive MSVC version support, it seemed to only make sense to me that the included C++ standard library would eventually have such support.

For our use case, we are writing system-level binaries and we don’t really have a choice in what runtime library we use or how we link – we’re forced to use this ancient runtime. I understand this is quite a narrow use case, which is why I proposed later VC versions as a much wider use case.

I understand supporting ancient runtimes is really a burden on the maintainers and I am sympathetic to arguments against merging. I’m happy enough maintaining a separate fork of these patches myself. Just thought I would gauge support for merging upstream.