[patch] [libcxx] [mingw] to r187593

[Reid Kleckner]

This looks good to me.

The mingw CRT vs. MS CRT situation is confusing.  We have this code in
llvm/Triple.h:
  /// \brief Is this a "Windows" OS targeting a "MSVCRT.dll" environment.
  bool isOSMSVCRT() const {
    return getOS() == Triple::Win32 || getOS() == Triple::MinGW32;
  }

The ifdef you're adding is the opposite of the above logic, but it makes
sense because IIUC mingw has its own headers and small static libs to paper
over the quirks of the MSVC CRT.  As far as libc++ is concerned, it's
basically a different C runtime.

I believe the Triple code is mostly used when deciding how to lower things
like large allocas to __chkstk.


On Thu, Sep 12, 2013 at 6:47 PM, G M <gmisocpp at gmail.com> wrote:

> Here's another attempt at restoring the ability for libcxx to compile
> again on mingw 64. link errors should remain whatever problem they
> previously were or were not.
>
> See r187593 for more details regarding this patch's necessity.
>
> Please advise of suggestions or if you know it breaks anything that wasn't
> already broken and how (real error messages please) and I'll see if I can
> revise it accordingly. Otherwise I'm keen for it to be applied ASAP as the
> mingw build has been broken since the date r187593 was applied.
>
> This patch should also reduce the number of errors when compiling with
> Visual Studio though on VS2013 RC. libcxx doesn't yet compile (at least how
> I am building) but it is close. I will be submitting more patches to
> improve that situation a little shortly.
>
> Thanks
>
> _______________________________________________
> cfe-commits mailing list
> cfe-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130916/1982466b/attachment.html>