[PATCH] D33082: Fix Libc++ build with MinGW64

Martell Malone via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Sun May 21 18:00:58 PDT 2017


martell added a comment.

I want to give some context here to dispel the confusion of what is and isn't win32 api specific.

First lets take `vasprintf` and `asprintf ` which are not implemented in msvcrt.
In mingw-w64 we would just have posix implementations of both.
They are hidden behind the guard `_GNU_SOURCE`, we don't need to declare them in `include/stdio.h` in libcxx but
By default gcc doesn't pass this flag for the mingw target so we should add it in cmake within libc++.
We should be able to guard mingw to stop it from picking up the implementations in `windows/support.cpp`

Next example

Example `mbsnrtowcs` and `wcsnrtombs` above
This is technically a win32api specific implementation in msvc. The mingw-w64 implementation or lack there of would rely on the MSVC implementation.
This is why a custom implementation lives in libc++ in `support.cpp` that is posix compliant.
Unfortunately a posix implementation might not be accepted upstream into mingw-w64 because they need to maintain compatibility with msvc, even with some bugs eek.
It generally comes down to if a bunch of projects are using it already and we should not disrupt them relying on msvc implementations/bugs.
This is probably not the case for these two functions but there are many others already in the library that follow this guideline.

A good read of this specific bug is here.
http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20130325/077071.html

@smeenai suggestion of `_LIBCPP_MSVCRT_LIKE` makes a lot of sense here because mingw-w64 is only partially posixy, this leaves room for future possible targets like midipix which uses musl libc to ignore this section of code where mingw and msvc opt in.


https://reviews.llvm.org/D33082





More information about the cfe-commits mailing list