[cfe-dev] Building Clang/LLVM with VS2013 for x86 & x64 - problems and questions

Tue Mar 24 11:09:24 PDT 2015

> On Mar 24, 2015, at 9:30 AM, Reid Kleckner <rnk at google.com> wrote:
> 
> On Mon, Mar 23, 2015 at 5:22 PM, David Bakin <davidbak at gmail.com <mailto:davidbak at gmail.com>> wrote:
> Hi!  I'm new to Clang/LLVM and I'm trying to use Clang as a parser/semantic analyzer for a tool I'm trying to write (details on request if you'd like).  I'm having trouble building, having following directions from the Clang site, the book "Getting Started with LLVM Core Libraries", and a couple of other sites mashed together.
>  
> a) Using cmake-gui and selecting "Visual Studio 12 2013" I got a set of VS project files that only had a Win32 configuration, no x64.  So to build x64 it must be necessary to select generator "Visual Studio 12 2013 Win64"?  And therefore 32-bit vs 64-bit determined by the "generator" and not by LLVM_TARGETS_TO_BUILD (which apparently only has X86 and not also X64)?
> 
> Right, we don't support generating a single VS solution that supports building LLVM in both 32 and 64-bit.

I could be wrong, but I actually think this is a painful limitation of CMake. I believe CMake implements Win32 and Win64 as different generators rather than a configure-time setting, which would make this very difficult to support. Conversely OS X’s multi-arch support is done via a configure time variable (CMAKE_OSX_ARCHITECTURES). Oddly enough I find that to be a terrible name because it really just sets the clang -arch flag, and it works for OS X and iOS, and it should work for Linux too if you use clang (although I’ve never tested it).

> 
> LLVM_TARGETS_TO_BUILD controls the set of backends to build, not the architecture you are currently targeting. Because x86 and x86_64 are so similar, all the code for both is part of the X86 target. Therefore, there is no separate X64 target, and you can just enable the X86 backend.
> 
> b) That set of project files didn't build DEBUG - I got errors from projects RTAsan_dynamic.i386 and RTAsan.i386 that they don't build DEBUG (only RELEASE). (Message from asan_win.cc in both cases.)  Can I just remove the DEBUG builds from those two projects, thereby building them for release even in the debug build?  And, for curiosity, what is the actual limitation there?
> 
> You don't need to build compiler-rt to build a semantic analyzer, so I would remove it from your checkout, honestly.
> 
> ASan doesn't support using the debug CRTs because they greatly complicate heap interception. For now, ASan should probably just force the usage of the release CRT regardless of what the user chose. Eventually we should support the debug CRT when we figure out proper interception.
>  
> c) That set of project files also had an error building clang_rt.asan-dynamic.i386 with LINK.EXE complaining about a bunch of switches (that look to me like compiler switches).
> 18>LINK : warning LNK4044: unrecognized option '/Oy-'; ignored
> 18>LINK : warning LNK4044: unrecognized option '/GS-'; ignored
> 18>LINK : warning LNK4044: unrecognized option '/Zi'; ignored
> 18>LINK : warning LNK4044: unrecognized option '/wd4146'; ignored
> 18>LINK : warning LNK4044: unrecognized option '/wd4291'; ignored
> 18>LINK : warning LNK4044: unrecognized option '/wd4391'; ignored
> 18>LINK : warning LNK4044: unrecognized option '/wd4722'; ignored
> 18>LINK : warning LNK4044: unrecognized option '/wd4800'; ignored
> 18>LINK : warning LNK4044: unrecognized option '/GR-'; ignored
>  
> What's the fix for that?
> 
> It's not fixed yet. :) As a workaround, don't build compiler-rt, I don't think you need it.
>  
> d) Finally, I also tried configuring an x64 build using generator "Visual Studio 12 2013 Win64" but cmake-gui complained at the selections I made as follows:
>  
> CMake Error at tools/llvm-shlib/CMakeLists.txt:48 (message):
> Auto-generation not implemented for Win32 without GNU utils. Please
> specify LLVM_EXPORTED_SYMBOL_FILE.
>  
> What's the proper way to fix that?  By which I mean ... is there some kind of more complete documentation of the use of CMake in LLVM than http://llvm.org/docs/CMake.html <http://llvm.org/docs/CMake.html> (the option LLVM_EXPORTED_SYMBOL_FILE doesn't appear on that page and anyway doesn't sound like that's the real problem)?

The LLVM_EXPORTED_SYBMOL_FILE is a variable you set to the path of a file containing the export list you want to pass to the linker. I’m not aware of anyone using llvm-shlib (LLVM_BUILD_DYLIB) on Windows, so I don’t know how functional that build tooling will be. If you need dlls rather than static libraries you might try using the BUILD_SHARED_LIBS option instead.

-Chris

> 
> Don't enable LLVM_BUILD_LLVM_DYLIB if you don't need it. Maybe we should document how this works better.
>  
> I hope all of you more experienced LLVM developers will put up with a newbie with newbie questions for awhile.  Thanks in advance! (And let me know if there's a better place to get questions answered, perhaps SO?)
> 
> -- David Bakin
> 
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu <mailto:cfe-dev at cs.uiuc.edu>
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev <http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20150324/09037083/attachment.html>