On Tue, Aug 27, 2013 at 8:48 AM, Nico Rieck <[email protected]> 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 > [email protected] > http://lists.cs.uiuc.edu/**mailman/listinfo/cfe-commits<http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits> >
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
