[libcxx-dev] libcxx on MSVC6.0 runtime

[Eric Fiselier via libcxx-dev]

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.

[1] https://ci.appveyor.com/project/llvm-mirror/libcxx

On Tue, Mar 5, 2019 at 4:43 PM Ben Craig via libcxx-dev <
libcxx-dev at lists.llvm.org> wrote:

> 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).
>
>
>
> *From:* libcxx-dev <libcxx-dev-bounces at lists.llvm.org> * On Behalf Of *Shoaib
> Meenai via libcxx-dev
> *Sent:* Tuesday, March 5, 2019 3:15 PM
> *To:* libcxx-dev at lists.llvm.org
> *Subject:* [EXTERNAL] Re: [libcxx-dev] libcxx on MSVC6.0 runtime
>
>
>
> (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?
>
>
>
> *From: *Brendan Heinonen <brendan at heinonen.co>
> *Date: *Thursday, February 28, 2019 at 9:48 AM
> *To: *Shoaib Meenai <smeenai at fb.com>
> *Subject: *Re: [libcxx-dev] libcxx on MSVC6.0 runtime
>
>
>
> We build against the Windows 7 SDK, which includes the system MSVCRT.
> VC6.0 is a bit of a misnomer, the system MSVCRT is really a fork of VC6
> with some later features mixed in, though VC6 ABI compatibility is
> guaranteed.
>
>
>
> Since we replaced cl.exe with Clang, It’d be nice to get some modern STL
> features too.  The patch would also theoretically enable compatibility for
> MSVC13.0 and below, which is probably a wider use case.
>
>
>
> On Thu, Feb 28, 2019 at 12:35 Shoaib Meenai <smeenai at fb.com> wrote:
>
> What's the motivation here? Is it classic MinGW compatibility (since that
> still uses msvcrt.dll, as far as I know), or something else?
>
>
>
> *From: *libcxx-dev <libcxx-dev-bounces at lists.llvm.org> on behalf of
> Brendan Heinonen via libcxx-dev <libcxx-dev at lists.llvm.org>
> *Reply-To: *Brendan Heinonen <brendan at heinonen.co>
> *Date: *Thursday, February 28, 2019 at 9:21 AM
> *To: *"libcxx-dev at lists.llvm.org" <libcxx-dev at lists.llvm.org>
> *Subject: *[libcxx-dev] libcxx on MSVC6.0 runtime
>
>
>
> Hi,
>
>
>
> 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:
>
>
>
> #ifndef _LIBCPP_VCRUNTIME_NO_C11
> using ::vfscanf;
> using ::vsscanf;
> #endif
>
>
>
> Thanks.
>
>
> --
>
> *Brendan Heinonen*
>
> H6N Technologies, LLC
>
> brendan at heinonen.co
>
> --
>
> *Brendan Heinonen*
>
> H6N Technologies, LLC
>
> +1 (832) 736-4346 | brendan at heinonen.co
> _______________________________________________
> libcxx-dev mailing list
> libcxx-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/libcxx-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/libcxx-dev/attachments/20190306/a8c138f9/attachment.html>