Building Clang/LLVM with VS2013 for x86 & x64 - problems and questions

Clang Frontend
1

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)?

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?

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?

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 (the option LLVM_EXPORTED_SYMBOL_FILE doesn’t appear on that page and anyway doesn’t sound like that’s the real problem)?

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

2

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.

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. :slight_smile: 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
Building LLVM with CMake — LLVM 18.0.0git documentation (the option LLVM_EXPORTED_SYMBOL_FILE
doesn't appear on that page and anyway doesn't sound like that's the real
problem)?

Don't enable LLVM_BUILD_LLVM_DYLIB if you don't need it. Maybe we should
document how this works better.

3

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

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

4

Thanks for your help. I’ve got clang built now … and I’m trying to confirm it works.

I’ve built an x64 version using the Visual Studio 2013 toolchain (as I described previously). Following your suggestions I eliminated compiler-rt and left llvm-shlib turned off (for the latter, I didn’t know what I was doing when I turned it on).

The unit tests for clang (built into …\tools\clang\unittests) all run successfully. I then tried to run tests using the command line “test harness” described here even though I’m not exactly sure what tests these are. The “test harness” required a little tweaking in the cfg files but I got it to run and the summary of results is:

Unresolved Tests (1):

Clang :: Index/annotate-comments.cpp
Expected Passes : 6460
Expected Failures : 20
Unsupported Tests : 178
Unresolved Tests : 1

Unexpected Failures: 174

So I’m not sure what this means but it probably isn’t good. “Unexpected Failures” seems awfully high - in fact, I assume that any number >0 is bad.

Any ideas on these failures? (I’ve attached the log file in case you’re interested in looking at it.) Alternatively, are there other ways to test my built Clang? (I’m not sure what I can do without compiler-rt.) Thanks! – David

lit.zip (36.2 KB)

5

My theory is that you have checked out the tests with DOS line endings, and they don’t pass that way.

This C++11 raw string failure, for example, shows an extra carriage return in the string literal:
“”"

R:\Sources\llvm\tools\clang\test\CodeGen\string-literal.c:91:18: error: expected string not found in input
// CHECK-CXX11: private unnamed_addr constant [8 x i8] c"abc\0Adef\00", align 1
^
:23:1: note: scanning from here
@.str16 = private unnamed_addr constant [9 x i8] c"abc\0D\0Adef\00", align 1
^
:23:11: note: possible intended match here
@.str16 = private unnamed_addr constant [9 x i8] c"abc\0D\0Adef\00", align 1
^
“”"

Many other tests fail with messages like this:
error: ‘R:\Sources\llvm\tools\clang\test\ARCMT\whitelisted/header1.h.result’ is different than ‘C:\TEMP\header1.h-5c694d…h’

That suggests that the test compared golden expected test result files with carriage returns with output written by clang, which will probably not have carriage returns.

6

A while ago, I tried building and testing LLVM with MSYS2 instead of the old MSYS. I saw a similar large number of unexplained failures. At first it looked like the problem was with grep from MSYS2 since many of the failing tests were using grep. After replacing MSYS grep with Gnuwin32 grep, many other problems still remained.
I did not checked this further, so if you are using MSYS2 it may be the same problem. See

http://sourceforge.net/p/msys2/tickets/89/

Yaron

7

Doh! Thanks! – David

8

I’ve reset everything in my working directories to use LF not CRLF and rebuilt everything and …

I get 147 unexpected failures and I believe they’re all of the form “fatal error: could not acquire lock file for module ‘xxx’”.

So I’ve done something stupid with my setup or didn’t clean up from a previous run properly or something … but what?

(Reminder: This is Windows, Visual Studio 12 2013 Win64.)

– David Bakin