search for: _win32_winnt

...ou I am trying to build the R grpc package on windows: https://github.com/nfultz/grpc against an MSYS2 build of grpc. when running devtools::install() I am getting the following error: C:/msys64/mingw64/include/grpc/impl/codegen/port_platform.h:47:2: error: #error "Please compile grpc with _WIN32_WINNT of at least 0x600 (aka Windows Vista)" #error \ ^ Which, if I am correct asks me to set _WIN32_WINNT=0x600 My Makevars.Win looks as follows: PKG_CPPFLAGS=-IC:/msys64/mingw64/include PKG_LIBS=-LC:/msys64/mingw64/lib -lgrpc What should I do? Have a great day best regards Witek -- Wit...

That's because when I am using Mingw to compile llvm. It's report can't find the API DWORD WINAPI GetProcessId( __in HANDLE Process ); In Mingw it's defined as #if (_WIN32_WINNT >= 0x0501) WINBASEAPI DWORD WINAPI GetProcessId(HANDLE); #endif but IN Wnidows SDK, there is nothing around GetProcessId. But from MSDN GetProcessId Function Retrieves the process identifier of the specified process. Syntax DWORD WINAPI GetProcessId( __in HANDLE Process ); Parameters P...

OK, it's not that bad - it's even better than before :) The main issue is RWMutex.inc and the use of PSRWLOCK. This requires _WIN32_WINNT to be >= 0x0600, which is not true for VS2005 SP1. Rather than #define _WIN32_WINNT 0x0600 (the file notes that this should build on all Win32 variants), extending the copy/paste of winbase.h to this works fine: #if defined(__MINGW32__) || _WIN32_WINNT < 0x0600 I'm still getting random...

Hi, what are the goals of VS2005 support for building LLVM? I'm syncing to the v3 branch and while the branch compiles perfectly with VS2008, there are a significant amount of compile errors and warnings with VS2005 SP1 (8.0.50727.867 with KB926601 SP1, to be precise). I also have the latest WSDK installed. A few months back there were only a few minor issues that I managed to clear up.

On Tue, Nov 8, 2011 at 8:02 AM, Don Williamson <don.williamson at yahoo.com> wrote: > > > OK, it's not that bad - it's even better than before :) > > The main issue is RWMutex.inc and the use of PSRWLOCK. This requires _WIN32_WINNT to be >= 0x0600, which is not true for VS2005 SP1. > > Rather than #define _WIN32_WINNT 0x0600 (the file notes that this should build on all Win32 variants), extending the copy/paste of winbase.h to this works fine: > > #if defined(__MINGW32__) || _WIN32_WINNT < 0x0600 > > I...

In the v7.0 SDK I see _WIN32_WINNT defined in several places: winresrc.h0x0500 if not defined already (Windows 2000) sdkddkver.h0x0601 if not defined already (Windows 7) objbase.hSet based on NTDDI_VERSION, if not defined already objidl.hSimiler to objbase.h sdkddkver.h is included by windows.h in the v7.0 SDK. With SP1 VC2005, i...

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

...:30 PM Subject: Re: [LLVMdev] VS2005 compatibility On Tue, Nov 8, 2011 at 8:02 AM, Don Williamson <don.williamson at yahoo.com> wrote: > > > OK, it's not that bad - it's even better than before :) > > The main issue is RWMutex.inc and the use of PSRWLOCK. This requires _WIN32_WINNT to be >= 0x0600, which is not true for VS2005 SP1. > > Rather than #define _WIN32_WINNT 0x0600 (the file notes that this should build on all Win32 variants), extending the copy/paste of winbase.h to this works fine: > > #if defined(__MINGW32__) || _WIN32_WINNT < 0x0600 > > I...

Hi All, I 'm trying to build Omega 1.2.9, configure ran through, but when I do make I get error below. Any thoughts what I am missing? Thanks Noel make all-recursive make[1]: Entering directory `/xapian/xapian-omega-1.2.9' Making all in . make[2]: Entering directory `/xapian/xapian-omega-1.2.9' /bin/sh ./libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I./commo n

Hi all, I came across this page today: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winprog /winprog/using_the_windows_headers.asp Based on that, I think we need a patch for mkmf when on Windows that sets _WIN32_WINNT automatically based on platform. This is the basic code I''ve come up with: require "mkmf" require "win32ole" require "socket" # We need to get the exact version number and set _WIN32_WINNT accordingly host = Socket.gethostname cs = "winmgmts:{imperson...

No, the problem with StoreSDNode was that an argument as being called Value, which hid the class Value later on in the argument list. This also broke 2003 and was fixed a while ago. _WIN32_WINNT is not supposed to be predefined, so that warning shouldn't be occurring. I have never seen it myself, and a predefined value could be inappropriate. Most of the other changes seem to be about inserting casts, and I'd like to know what errors they are fixing. The casts are not needed...

On 3/11/07, Reid Spencer <rspencer at reidspencer.com> wrote: > Could you submit the patch? We could make sure that 2.0 doesn't have the > same problem. Sure, I can't test this from where I am now but if anyone can take it for a spin to test it and verify the fix then by all means check it in. I'm just providing a hand-edited diff from our vendor branch here (1.9 tarball

...; wrote: > No, the problem with StoreSDNode was that an argument as being called Value, > which hid the class Value later on in the argument list. This also broke > 2003 and was fixed a while ago. Ok, I didn't know that. We've been using the 1.9 tarball version, as I said. > _WIN32_WINNT is not supposed to be predefined, so that warning shouldn't be > occurring. I have never seen it myself, and a predefined value could be > inappropriate. Many win32 projects define this globally when they need some specific target version of the platform SDK. Maybe the correct way would...

...;>> >>>> 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 &g...

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

...lt;gregbedwell at gmail.com> wrote: > Hi all, > > 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...

...l, > >> > >> 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 >...

.... This also >> broke >> 2003 and was fixed a while ago. > > Ok, I didn't know that. We've been using the 1.9 tarball version, as I > said. Just to make clear, there are no problems building 1.9 with VS 2003, nor are there any problems as I write this. > >> _WIN32_WINNT is not supposed to be predefined, so that warning >> shouldn't be >> occurring. I have never seen it myself, and a predefined value could be >> inappropriate. > > Many win32 projects define this globally when they need some specific > target version of the platform...

...;> >> 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 s...

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