[patch] libcxx win32 support

Reid Kleckner rnk at google.com
Tue Aug 27 10:31:36 PDT 2013


On Tue, Aug 27, 2013 at 8:48 AM, Nico Rieck <nico.rieck at gmail.com> wrote:

> On 27.08.2013 16:55, G M wrote:
>
>> As can be seen by the table above, the effect of the earlier change
>> means that some files that might have previously only compiled #if
>> _MSC_VER are now instead getting compiled in the more general _WIN32 mode,
>> letting clang etc. in which is a situation they aren't prepared for.
>>
>
> Then why not just revert to the previous state by taking Mingw out of
> _LIBCPP_MSVCRT (because they aren't fully compatible to the real one),
> and change a few guards here and there to include Mingw? I've attached a
> patch like that before.
>

Ah, now I actually see what the problem is.  Yes, this seems like the right
way to go.  It's unfortunate that we haven't yet figured out a better way
to detect the Microsoft CRT and its headers.


> It only changes a few spots and makes a lot of your changes unnecessary.
> To me that seems a lot easier instead of pulling on all the workarounds not
> intended for Mingw.
>
>
>  I wonder if at that time those files were written _MSC_VER might have been
>> meant "for Microsoft's compiler only" but I don't know, But in any case, I
>> think this is what broke the mingw/gnu toolset that I use so it no longer
>> compiled "out of the box".
>>
>
> I want to ask again: How do you (or did you) compile libc++ with Mingw
> "out of the box"? Because if I do so, I get undefined references when
> linking, so can't further check up on this.
>
>
>  I don't know the intent of the changes above and without that I
>> personally find the new macro's more confusing than just using #if _WIN32
>> etc. here, but I don't feel confident enough to argue that case.
>>
>
> The intent is stated in r187593. If you have clang and a different C
> standard library (I wrote one from scratch for clang) then a lot of the
> workarounds are unnecessary/wrong/problematic. And the latter were pulled
> in unnecessarily because of wrong guards. And not every Windows-specific
> code are compiler or standard library workarounds (though libc++ does not
> include anything in this category yet).
>

And so you don't define _WIN32 to avoid that code?

Regarding your patch, just a small note, there is quite a bit of noise in
> there (e.g. unnecessary whitespace changes). It wuold be nicer to not
> include those.
>
>
> -Nico
> ______________________________**_________________
> cfe-commits mailing list
> cfe-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/**mailman/listinfo/cfe-commits<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/20130827/ae05f0ba/attachment.html>


More information about the cfe-commits mailing list