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

Wed Mar 25 09:02:37 PDT 2015

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
                 ^
<stdin>:23:1: note: scanning from here
@.str16 = private unnamed_addr constant [9 x i8] c"abc\0D\0Adef\00", align 1
^
<stdin>: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.

On Tue, Mar 24, 2015 at 9:52 PM, David Bakin <davidbak at gmail.com> wrote:

> 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
> <http://clang.llvm.org/hacking.html#testingCommands> 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
>
> On Tue, Mar 24, 2015 at 11:09 AM, Chris Bieneman <cbieneman at apple.com>
> wrote:
>
>>
>> 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> 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 (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
>>> 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/20150325/7a00cb80/attachment.html>