compnerd added a comment. In https://reviews.llvm.org/D34588#802533, @bruno wrote:
> > Thinking more about this, on Windows, is there a strong reason to default > > to a different libc by default on Windows? > > I'm mostly concerned with `-fms-extensions` + darwin, which doesn't apply to > this scenario, maybe someone else knows a better answer here. Could something like _WIN32 && _MSC_VER make this better? That would allow us to differentiate between the various environments. It's kinda icky, but, does make sense in a round about way. > > >> @bruno would reusing `-ffreestanding` work for you here? > > I think forcing the use of `-ffreestanding` with Apple platforms just for > this is too restrictive. Okay, was worth the shot anyways. >> Or is there something else that we can identify about the target environment >> that can indicate that the MS CRT is unavailable? I think that what is >> weird to me about this is that this is not about compatibility with Visual >> Studio but about the underlying libc. It feels like it would be similar in >> spirit to say that libc++ defaults to libSystem as the underlying libc on >> Linux. > > Right, makes total sense. I'm assuming that `-fms-extensions` for other > targets (Linux) will also rely in not using `_LIBCPP_MSVCRT`, however > #ifdefing for other platforms here doens't seem to add much because they > usually do not set `_MSC_VER` anyways. Additional ideas? Another bad idea: -U_MSC_VER. The undefine should come after the preprocessor is initialized and should have the same effect as not having it defined. https://reviews.llvm.org/D34588 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
