Hey folks, apologies for the rather noobish email...
I'd love to get into clang (and maybe llvm?) development, as some of my
projects use it as a "black box" that I'd "unbox" that, to make it easier
to debug if nothing else. At the moment, the project I'm working on works
great on Mac OS X, but fails miserably for unknown reasons on Windows.
I took a read of http://clang.llvm.org/docs/MSVCCompatibility.html and it
recommended using mingw32 instead of MSVC where possible, but this would
mean porting the (very large) project over so that it works on mingw32,
which would take a large but doable amount of time.
My question is, if I spend the time to get everything working on mingw32,
is clang in a state to "mostly work" on Window after that (assuming my
application code isn't doing anything stupid)? To be a little more
specific, clang is being linked against to compile C++ code that is later
run (i.e. it's not for static analysis). If mingw32 isn't in such a state,
is the MSVC version? The link I posted above gives me some information
about this, and I'm OK with only compiling for 64 bit (as the exception
comments mention that 64 bit exceptions are in a decent state), but I don't
know anything beyond what's in that article.
Thank you very much for any help in advance!
My limited experience with clang on Windows thus far is that for most purposes it is no longer necessary to use mingw. The linked page that mentions it, does so specifically in the context of ABI compatibility, i.e. some of your code is compiled with clang, some with another compiler using at least moderately exotic C++ features and there is a need to link them together. Does your project require that, or is it possible to do things another way e.g. compile everything with clang?
Thanks for the quick reply!
The project is compiled using MSVC at present, which in turn links against clang (compiled with MSVC), the Windows VC++ runtime libraries and uses Windows API calls. Internally, it compiles programs with clang for running on Windows that in turn use Windows API calls. You can think of the whole thing as a GUI wrapper around clang on Windows (it’s a lot more than that, but that gives you an idea of how clang is being used).
That’s basically the configuration I’m using thus far too, so if there are problems with it, I’d like to know about them in case they’re problems I’m going to run into in the near future! Why is that configuration not working for you? What sort of errors are you getting?
I’m using Visual C++ 2015 and clang 3.7.0, with everything set to 64-bit, is that the same as you have?
I’m using Visual Studio 2013 (just because we suppose it’ll be better tested etc) with revision 245761 of clang, compiler-rt and llvm. I’m also using the ORC JIT engine to compile the C++ code.
The errors we’re getting are non-deterministic, which is what is making it so hard to figure out.
Are you building the release from source, and if so, what cmake flags are you using? Any other things I should know about that you use to build your project?
Much appreciated as always,
I'm using Visual Studio 2013 (just because we suppose it'll be better
tested etc) with revision 245761 of clang, compiler-rt and llvm. I'm also
using the ORC JIT engine to compile the C++ code.
Current revision seems to be 246... so that's pretty recent, right?
Is there a reason you need to use compiler-rt?
The errors we're getting are non-deterministic, which is what is making it
so hard to figure out.
As in, crashes due to stray pointers?
Are you building the release from source, and if so, what cmake flags are
Any other things I should know about that you use to build your project?
Current project build procedure:
if "%VCINSTALLDIR%"=="" call "C:\Program Files (x86)\Microsoft Visual
Studio 14.0\VC\vcvarsall" x64
cl /Fea /I\llvm\build\include /I\llvm\include /I\mpir /MP /MTd *.cpp
I also just ran a test trying to compile my project with clang and link it with all the libraries that had been compiled with Microsoft C++:
clang-cl -fms-compatibility-version=19 /J -I\llvm\build\include -I\llvm\include -I\mpir /MTd *.cpp \llvm\build\Debug\lib*.lib \mpir\build.vc14\lib_mpir_core2\x64\Debug\mpir.lib
And it all worked fine, even though a fair number of C++ features were used. To emphasise, this is linking C++ object files compiled with different compilers, something traditionally considered theoretically impossible, and it works! Exceptions are the main things I don’t use, because they are still apparently a work in progress.