August 9th, 2012  »  Programming  »  23 Comments

I have updated my prebuilt ‘Clang/LLVM for Windows’ to the latest and greatest. Find the August 2012 package over here.

There were some annoyances trying to get ClangVSx working on Visual Studio 2012 RC, which are now fixed. I have uploaded a small point-release to GitHub, find the details on the ClangVSx page.

The two stumbling blocks for getting the 2010 version of the add-in working were:

  • Forgetting to update the 2010-specific assembly references in the project; namely Microsoft.VisualStudio.VCProjectEngine & Microsoft.VisualStudio.VCProject
  • 2012 returns the hidden .filters file in the VCProject.Files collection, which happens to then throw an exception when you ask if it is ExcludedfromBuild. Wrapping access to these freaky dynamic objects saves the system from failing and we just skip anything that doesn’t support the required interfaces.

Anyone using either of these projects – please let me know bugs and issues, either via the comments system on the site or via GitHub!


23 Responses to ClangVSx 3.2 with 2012 RC support, Clang-Win32 updated

    Eric K. Marks says:

    Splendid work!

    This version works much better than the previous versions I’ve tried. My remarks (for VS 2010):

    1. I had to disable /Wall and /arch:AVX, and had to use /SUBSYSTEM:CONSOLE.
    2. I am using property pages in Visual Studio. Somehow the include settings, inherited by my property pages, do not get onto the command line. Not a huge problem.
    3. I had to enable -std=c++0x. Oh well :). But isn’t the primary reason for Clang in Visual Studio the almost complete support of C++11? I think so. Not really a problem either.
    4. In essence, my only problems are 4 Microsoft standard library headers (iosfwd, limits, xstring, xlocale), when using std::strings/ios of wchar_t / (un)signed int (i.e. for Unicode stuff). See for minimal test case, and for output.

    ishani says:

    Hi Eric, glad you’re getting some use out of it!

    2. Do you happen to have a simple repro case of this? You wouldn’t believe the hoops I have to jump through when working with the VS ‘SDK’ to get proper evaluated data out of various points in the build pipeline. If you can point me at a specific fault I can have a go at fixing it.

    3. Yes, I have this sat in my settings but it probably should be a standard addition; I will likely add a few default command line options as check-box toggles and have C++11 on by default.

    4. This is a weird one. There are specific settings in Clang that don’t define char16_t and char32_t when it’s running in ‘Microsoft Mode’. So when we enable C++11 and those templates expect those types to be defined, they aren’t, hence the errors. You can manually disable these via a “#define _HAS_CHAR16_T_LANGUAGE_SUPPORT 0″ but iostream then manages to crash the compiler with an unreachable-path exception.

    .. maybe time to try STLPort!

    Eric K. Marks says:

    >2. Do you happen to have a simple repro case of this?
    Nevermind. My VS solution file was apparently damaged; after recreating the solution everything works properly.

    >4. This is a weird one.
    Only a short note from my side: You don’t actually have to use any Unicode stuff, already including causes those compile errors.

    But it is very nice to see that you put so much effort into the VS integration of Clang; thank you. I still have two small suggestions/questions:

    5. Can you couple the solution platform (Win32/x64) with the corresponding Clang target (i686-pc-win32/x86_64-pc-win32), so that a change of the solution platform automatically changes the Clang target?

    6. Will it be possible to debug Clang-compiled applications with the VS debugger? Currently (when I write a program with an infinite loop, and attach the VS debugger to that running process) I can see the disassembly in VS, but “Go to source code” is greyed out. Is that an architectural hurdle impossible to overcome?

    Eric K. Marks says:

    >already including causes those compile errors.
    should read “already including iostream causes those compile errors.”, but the pointy brackets and the word itself around “iostream” got removed by the blog software.

    Oh and I got another one:

    6. Did you remove the following menu item?
    I for one cannot find it in my menu; having an option to run the Clang analyzer would be nice.

    ishani says:

    5: Yes, this is on the to-do list.

    6: Well there are two possibilities here – one would be for Clang/LLVM to emit a PDB file instead of embedding DWARF debugging data; in that case, the VS debugger should (in theory) “just work”. The other option would be for me to write a Debug Engine extension for VS that could parse DWARF data. Someone did propose PDB support as a GSoC 2012 project but I don’t think it got picked up. So I guess the short answer is “not yet, but very possibly in the future :)”

    6b: I didn’t, that menu should still be there. Checked and working in latest build as of 2mins ago. Could try removing and reinstalling the add-in perhaps?

    Eric K. Marks says:

    6b. Well, this is embarrassing. I thought the menu item would be in the Edit menu. It is in the (right-click) context menu, and works properly. Sorry about that!

    But still another suggestion:

    7. In the post-build events of the ClangVSx solution, please add quotation marks around all paths; some people have spaces in their user names, and so does their desktop path.

    ishani says:

    If you get latest from GitHub, points 5 and 7 are now fixed.

    Eric K. Marks says:

    Yup, works as advertised :)

    jrb says:

    do the compiled executables use the msvc runtime and standard lib or the mingw/gcc libs

    ishani says:

    These are compiled with Visual Studio 2010 SP1, so you’ll need these redistributables installed if you don’t have VS :

    Devid says:

    If I try to compile this simple code for x64 on VS2012:
    int _tmain(int argc, _TCHAR* argv[]) {
    int *ptr = new int;
    delete ptr;
    return 0;

    and using following clang options:
    -std=c++0x -Xclang -cxx-abi -Xclang microsoft -D_ITERATOR_DEBUG_LEVEL=0

    Then I will get flowing error messages:

    Win64Project.obj : error LNK2019: unresolved external symbol “void * __cdecl operator new(unsigned __int64)” (??2@YAPAX_K@Z) referenced in function “int __cdecl wmain(int,wchar_t * * const)” (?wmain@@YAHHQAPA_W@Z)
    Win64Project.obj : error LNK2019: unresolved external symbol “void __cdecl operator delete(void *)” (??3@YAXPAX@Z) referenced in function “int __cdecl wmain(int,wchar_t * * const)” (?wmain@@YAHHQAPA_W@Z)
    msvcrt.lib(crtexe.obj) : error LNK2019: unresolved external symbol main referenced in function __tmainCRTStartup

    Do some one has any Idea how to fix this ???

    Devid says:

    Well apparently on x64 __int64 is missing.

    “??2@YAPEAX_K@Z” “void * __ptr64 __cdecl operator new(unsigned __int64)”
    “??3@YAXPEAX@Z” “void __cdecl operator delete(void * __ptr64)”

    Devid says:

    Of course I mean __ptr64
    This must to be something wrong in MicrosoftMangle.cpp

    Probably in this function:

    ishani says:

    It’s almost certainly the mangler at fault – or rather, simply incomplete. I’m not up to date with how polished the MicrosoftCXX version is (last time I looked clang was defaulting to the Itanium ABI on Windows targets, as that was the only one vaguely complete)

    Devid says:

    Yes if I remove “-Xclang -cxx-abi -Xclang microsoft”
    then I will get
    error LNK2019: unresolved external symbol _Znwy referenced in function main
    error LNK2019: unresolved external symbol _ZdlPv referenced in function main
    for new and delete.

    But with “-Xclang -cxx-abi -Xclang microsoft” you can force clang to use “not complete” Windows/VS ABI.

    Now I am truing to figure out how to __ptr64 support to the Clang Mangler…

    Devid says:

    By the way ClangVSx is great to play with Clang on Windows, thank you!

    Is there a way to add support for DLL compilation and not only Console?
    The problem appears to be the SubSystem, for now only SUBSYSTEM:CONSOLE will be supported right ?

    ishani says:

    It should be fine compiling for any of the default subsystems, I have DLL and windowed test apps in my little test suite. I have noticed that sometimes VS just clears the subsystem selection when adding new platform targets, so check that it’s set correctly if you’re having problems.

    JM says:

    Hi. Thanks for this awesome addin. Your work is much appreciated!

    I know you’re not my VS technical IT assistant, but I need some help. I have installed VS2012 and have followed your instructions to the T, along with troubleshooting with the rest of the internet, and cannot solve a problem.

    VS2012 doesn’t seem to have noticed the addin, or addins at all. In the TOOLS or OPTIONS menu, I see no reference to Addins whatsoever (but I do see Extentions but those seems entirely separate). Is this a standard issue? Do you know of any way around this?


    ishani says:

    Hi JM – Are you using VS2012 Express by any chance?

    If not, just to check, you added the directory to the add-ins options as mentioned on my blog?

    If so, Express doesn’t support add-ins :(

    JM says:

    I am using express. Good to know and thanks for your speedy and informative reply!

    Devid says:

    Here is the Fork of ClangVSx where I am truing to add more options…

    Krishty says:

    @JM: ClangVSX not being recognized was a standard issue on my systems, with VS 2010 as well as VS 2012.
    You need to open devenv.exe.config to set loadFromRemoteSources. (Search that keywords for exact how-to’s).
    Finally, run Visual Studio as an administrator.
    ClangVSX now works for me with VS2010 Professional and VS2012 Express.

    @all: I cannot get anything linked, though. Any function not defined in my project (CRT, Windows SDK) will simply not be found; neither will be lots of RTTI stuff. If I use “-Xclang -cxx-abi -Xclang microsoft”, at least six source files will crash — always while compiling constructors, destructors or exception handling. Any ideas?

    Devid says:

    Well the problem is that -cxx-abi microsoft is totally not complete and so is very buggy in current Clang.

    If you not define this then Clang will use Itanium C++ ABI witch is not compatible with Microsoft one.
    So all C++ names will be mangled different and so can not be resolved while linking.

    For not is also only possible to link against C library on windows.
    But you still can use Clang for Static Analysis and to test if you code will compile with Xcode…

Leave a Reply

Your email address will not be published. Required fields are marked *