similar to: [LLVMdev] RFC: Drop support running LLVM on Windows XP

We formally support our toolchain only on Windows 7 onward, so it's okay with us. (Please make sure this goes in the release notes when you start doing something not supported in XP and/or Vista.) --paulr From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Jim Rowan Sent: Friday, October 31, 2014 1:05 PM To: Reid Kleckner Cc: LLVM Developers Mailing List

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

On Mon, Oct 5, 2015 at 2:18 PM, Hans Wennborg via llvm-dev <llvm-dev at lists.llvm.org> wrote: > (cc'ing the new list address; sorry for the duplicate) > > On Mon, Oct 5, 2015 at 11:14 AM, Hans Wennborg <hans at chromium.org> wrote: >> Did we conclude that we've dropped Win XP support now? I believe we have, yes. ~Aaron >> >> If so, I'll stop

+1. We may focus Windows 7, aka NT6.1, as the baseline. 2015年7月14日(火) 7:48 Aaron Ballman <aaron at aaronballman.com>: > On Mon, Jul 13, 2015 at 6:26 PM, Reid Kleckner <rnk at google.com> wrote: > > 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 > >

On Fri, Jul 31, 2015 at 9:09 AM, Greg Bedwell <gregbedwell at gmail.com> wrote: > 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

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 On 14 July 2015 at 06:55, NAKAMURA

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

> > 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. +1 As long as the new APIs are also supported on current MinGW-w64 compilers, > I am for this switch. > May I also suggest dropping support for mingw.org toolchains for both hosts and targets They are pre windows 7 and only support

> > 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 >

Indeed, mingw and pthreads have C++11 atomics, so building clang (with atomics) should be possible even in cross compilation. I have no idea what is the win from *not* using winpthreads, it is one small DLL file with BSD license. For context (does not matter to mingw as host for buiilding clang but matters for clang running with mingw environment), clang TLS implementation is not same as mingw so

On 24 Sep 2014, at 05:59, Mueller-Roemer, Johannes Sebastian <Johannes.Sebastian.Mueller-Roemer at igd.fraunhofer.de> wrote: > <atomic> should work both in win32 and pthread versions of MinGW. <mutex> and <thread> are only supported in the pthread version though. <atomic> is trivial, as most of the support is provided by the compiler. As of Vista, Windows comes

Is there any method to copy files from the guest to host? I use virbr networking where the host and the guest have different static IPs. _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users

Is there any method to copy files from the guest to host? I use virbr networking where the host and the guest have different static IPs. _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users

On Tue, Nov 8, 2011 at 8:42 AM, Don Williamson <don.williamson at yahoo.com> wrote: > Hi Francois, > > I have all licensed versions of VS at my disposal (the benefits of being a former MS employee) but I'm currently using VS2005 due to specific technical reasons that I can't disclose. > > The "Getting Started" page states support of 2005 SP1 which, if

I've found that interception_win.cc line 835: "msvcr110.dll" //VS2012 "msvcr120.dll" //VS2013 interception is supported by commit 916b81 3 years ago , currently I'm build project with msvc100 , application will crash in un-intercepted free. adding msvcr100.dll to this list makes sanitizer working correctly , I wonder if compiler rt can including this msvc100.dll

On 6.5.2013 0:43, Timothy B. Terriberry wrote: > Janne Hyv?rinen wrote: >> You people do realize these hacks would only be required for 10+ year >> old obsolete compilers? > No, they're required for easy distribution on 12 year old OSes (which, > last I saw, make up almost 40% of Firefox's desktop userbase, and likely > will continue to for some time). > What

Hi, All, I follow the menu http://llvm.org/docs/GettingStartedVS.html , but still failed to build LLVM debug version. Here's error message: 7>C:\study\llvm\projects\compiler-rt\lib\asan\asan_win.cc(69): fatal error C1189: #error : Please build the runtime with a non-debug CRT: /MD or /MT Any idear? -- Best Regards, Amy -------------- next part -------------- An HTML attachment was

On Tue, Jan 27, 2015 at 10:02 AM, Mueller-Roemer, Johannes Sebastian <Johannes.Sebastian.Mueller-Roemer at igd.fraunhofer.de> wrote: > Adding -D__MSVCRT_VERSION__=0x900 (or higher) to CMAKE_CXX_FLAGS and > -lmsvcr90 (or higher) to CMAKE_CXX_STANDARD_LIBRARIES appears to work. > -lmsvcrt80 does not work, contrary to the comment on the MinGW bug tracker. > However, if you do not

AKA: MinGW + win32threads is holding LLVM (and all of its subprojects) back. We need to stop supporting this host platform. I'm aware of essentially 2 reasonably important use cases for supporting MinGW + win32threads: 1) Sane host toolchain on Windows that doesn't require downloading MSVC. (I'm dubious about the value of this one...) 2) Cross-compiling a Windows clang.exe (and

Hello I want to add Win7 machine to my Samba PDC with WinXP clients. Google tells me I have to add a .V2 to my profiles. The samba log ask about a .v2 share. Can someone explain me the difference of the v2 extension at the profile names and the roaming profile share? Following my settings: smb.conf: [global] logon path = \\%L\nt-profile logon home = \\%L\nt-profile [nt-profile]