I’d like to raise our baseline Windows system requirements to Vista, dropping support for running LLVM on Windows XP. Microsoft dropped support for XP half a year ago in April 2014.
Our current status is that we require VS 2012 to build LLVM, and VS 2012 only runs on Vista+, but it has the ability produce binaries that run on XP. During the C++11-pocalypse, users expressed interest in keeping this working. I’m proposing that we drop support for this.
Vista introduced a lot of handy system APIs that could significantly simplify LLVM’s Support library. For example, I’d really like to use the blessed one-time initialization routines in this CL: http://reviews.llvm.org/D5922
Vista also introduced a bunch of condition variable APIs that I know less about, but that’s another reason we might want to raise our base requirement as people look into parallel LTO and codegen. It also seems likely that we will want to use some of the new C++11 library features that are only present in newer CRTs, which don’t run on XP.
Please respond if you have any objections. If there are no strong objections, I think we can start using Vista+ APIs in a week or so. We can still change our minds and revert stuff before the release if users feel this is too short notice.
I'd like to raise our baseline Windows system requirements to Vista,
dropping support for running LLVM on Windows XP. Microsoft dropped support
for XP half a year ago in April 2014.
Our current status is that we require VS 2012 to build LLVM, and VS 2012
only runs on Vista+, but it has the ability produce binaries that run on
XP. During the C++11-pocalypse, users expressed interest in keeping this
working. I'm proposing that we drop support for this.
Vista introduced a lot of handy system APIs that could significantly
simplify LLVM's Support library. For example, I'd really like to use the
blessed one-time initialization routines in this CL: http://reviews.llvm.org/D5922
Vista also introduced a bunch of condition variable APIs that I know less
about, but that's another reason we might want to raise our base
requirement as people look into parallel LTO and codegen. It also seems
likely that we will want to use some of the new C++11 library features that
are only present in newer CRTs, which don't run on XP.
I would personally prefer we jump to Windows 7 instead. Windows 7
introduced useful condition variable APIs over what Windows Vista provided
like TryAcquireSRWLockExclusive.
It looks like this conversation stalled. I have a local patch that I’d like to send upstream (automatically generating Windows crash dumps on clang/LLVM crashes) that makes use of a Windows API function that requires _WIN32_WINNT set to 0x0600 at minimum so I’d like to restart the conversation!
As there have so far been no objections that I’ve seen and we’re branching imminently, it feels like a perfect time to make this change as soon as the release branch is taken, and adding a release note for 3.7 to the effect of it being the final version supporting XP. I don’t think there’s been a clear conclusion on what we should raise it to though.
Nobody objected to raising the bar, so I think we can go ahead and do this. Keeping the XP support until 3.7 ships seems reasonable as it’s less disruptive.
Should we consider bypassing Vista and jumping to 7 as the lowest supported Windows version as David suggested? I think we should document 7 as the recommended baseline. After we start using some of the newer APIs, we can see if users complain and evaluate the burden of maintaining Vista support at that time.
Nobody objected to raising the bar, so I think we can go ahead and do this.
Keeping the XP support until 3.7 ships seems reasonable as it's less
disruptive.
Agreed.
Should we consider bypassing Vista and jumping to 7 as the lowest supported
Windows version as David suggested? I think we should document 7 as the
recommended baseline. After we start using some of the newer APIs, we can
see if users complain and evaluate the burden of maintaining Vista support
at that time.
I think it's reasonable to switch to Windows 7 at this point. Vista's
mainstream support ended in 2012 and only has extended support until
2017, so it's sunsetting already.
It sounds like there are no objections to jumping to Windows 7 as the baseline. Is it worth getting a note added to the next LLVM weekly to give the potential change a bit of a wider viewership before going ahead with it or are we in a position to just do this now? If so, what are the actual mechanics of the change, and who’d like to do it?
Thanks!
-Greg
It sounds like there are no objections to jumping to Windows 7 as the
baseline. Is it worth getting a note added to the next LLVM weekly to give
the potential change a bit of a wider viewership before going ahead with it
or are we in a position to just do this now? If so, what are the actual
mechanics of the change, and who'd like to do it?
I think we should definitely get a note into the weekly update. We may
also want to get it into the 3.7 release notes as a warning to users.
I suspect we're in a position to make the switch now. As for the
mechanics, I'm less certain of all the places we have to touch, but
intuition suggests cmake and WindowsSupport.h.
I don’t think we support mingw.org as host since it lacks C++ 11 atomics. They may be leftover #ifdefs in the code which could be cleaned up.
As a target mingw.org toolchain itself is still quite popular. The mingw.org-specific code are just few lines locating the lib directory and adding an include path so we gain almost nothing by removing them. I personally do not use this toolchain but the mingw-w64 one.
I don’t think we support mingw.org as host since it lacks C++ 11 atomics. They may be leftover #ifdefs in the code which could be cleaned up.
I don’t see that in the docs but it makes sense that it is not supported.
As a target mingw.org toolchain itself is still quite popular. The mingw.org-specific code are just few lines locating the lib directory and adding an include path so we gain almost nothing by removing them. I personally do not use this toolchain but the mingw-w64 one.
Yes I am not saying that we should remove this code its very easy to keep.
I just think that if someone is experiencing issues with this setup though they should pointed to use mingw-w64 before filing issues as it is officially supported.
This is for all issues outside lib and include directories that is
All online documentation for the windows-gnu target should probably be mingw-w64 specific if there is any that is.