VS2005 compatibility


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. I'm going to try and fix up my local copy but is it worth my time - should I just move to VS2008 and accept that VS2005 support is being slowly deprecated?

- Don

OK, it's not that bad - it's even better than before :slight_smile:

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 crashes running llvm-tblgen.exe which I think is a known issue (I only need clang libs to build successfully so this isn't fatal for me).

- Don

I am not aware of anyone who regularly build LLVM/clang with MSVC 2005
so you might run into some problems.

I suggest you update to MSVC 2010 (or 2008 will do). There is a
buildbot for MSVC 2010 so issues are generally fixed quite fast. Also
LLVM compile just fine if you use the free MSVC Express edition so
having to pay for a license should not be problem.

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 it's not being maintained, is not true and should be updated.

- Don

I don't know about VS support being deprecated, but I'm more curious
as to what the issue is since you're using the latest Windows SDK.
That code should compile only for Vista+ SDKs, and should fallback on
the old critical section code for XP and lower. There's nothing
compiler specific about it -- just platform SDK specific. At least,
that was the intent.


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, it's defined as 0x0500 in only one place (winresrc.h).

So it looks like my build (using cmake) is not picking up the installed v7.0 SDK. This can be achieved by running a tool in the WSDK that makes your version "current" (it modifies the visual studio global include directories).

However, that's kind of moot since you can install VS2005 and not update to the latest WSDK. In fact, I only updated it because I was after GPUView.

Various MSDN documents say that if you want to compile for a minimum OS version then you need to define _WIN32_WINNT to be that version:

However, the code doesn't want to do this - it wants to check to see if certain functions are available at runtime and choose the best option available to it. But in order to write code that does that, it needs access to certain API structures to define the function signatures.

So to make this compile across all Windows platforms it needs to check to see if _WIN32_WINNT is below 0x0600 (Windows Vista) and take the same path as __MINGW32__. Or you require that to build in VS2005 you need the latest WSDK installed.

- Don

_WIN32_WINNT is defined explicitly as 0x0502 on lib/Support/Windows/Windows.h.

We need check post-vista API on configuring. I will fix it on ToT soon.

(It might be *regression*, 2.9 can be built on vs8)